rethink LODs

[Trass3r]

#431 uncovered a few problems with the current LOD setup.

KMFs are divided into multiple mesh groups, usually to be able to assign different materials but sometimes also for high-poly models like GemHolder to overcome group size limitations.

1 group	another

That leads to an unexpected distribution of triangle definitions over the groups and LODs, not the typical descending order.

KMFs define a global number of LODs and for a given level the corresponding mesh group levels are to be combined for the final mesh. If one is empty that group doesn't contribute to that level.
In JME otoh the LodControl determines the level to choose independently for each mesh group, leading to incorrect combinations.
One way to deal with this could be to merge mesh groups that use the same material. There's just this unknown variable mmFactor to consider (inverse factor in mipmap level decision (falloff?)?)

This hasn't surfaced yet cause the way LodControl works, together with the low polycounts, means we currently almost exclusively use LOD 0 anyway. One could try to tune the heuristic via

        lc.setDistTolerance(0.1f);
        lc.setTrisPerPixel(0.1f);

But overall it's questionable if the complexity of dealing with all this is worth any potential runtime gains given the low polycounts.