Added One Material per Mesh Func & "GlobalBounding" Splitting Strategy

[gojushin]

PR Summary

Adds support for --single-material-per-part a new GlobalBounding split strategy (--split-strategy GlobalBounding)

Single-material mode repacks each tile’s used diffuse and normal textures into a shared atlas, remaps UVs, and emits one material per part.

This is especially useful if the source mesh has UDIMs that are vastly scattered across the mesh.

The GlobalBounding split strategy creates a stable, source-derived square grid shared across LODs, with optional Z splitting based on the source bounds.

Both options are non-breaking changes, as they only extend existing functionality by providing additional CLI args.

Related Issue: None

What I did so far

• Implemented the described functionality.
• Did a full self-review to the best of my ability.
• Did a full self-test to the best of my ability.
• Updated Documentation.
• Updated Test Cases.

Remarks

• The Atlas Merge does not take into account tint or opacity/alpha values from the .mtl.
  In theory the other implementations could handle this better as materials are treated individually, but as far as I can tell the implementations mostly disregarded these too, which... assuming the kind of input we are working with... is fair.

• GlobalBounding Splitting also supports z-splitting, but functionality for it might work counterintuitively.
  Inputs are usually way larger in width and height, then in depth. Using --zsplit would create a longestSide³ Volume, which would almost always encapsulate all parts of one mesh in height and not perform any splits on z.
  To provide meaning to --zsplit, it uses sourceBounds.Min.Z and sourceBounds.Max.Z, splitting across the entire height of the mesh.
  (I documented this in both the code and in the README)

[gojushin]

After Testing, I can certainly say - this needs some more work.
While it generally seems to work, --single-material-per-part is extremely slow at the moment, taking upwards of 16 hours per tile on a high end workstation at LOD1.

I will look into it.

[gojushin]

Sooo. The issue is that the current BinPacking algorithm, which I reused for this, can't handle the massively higher amount of charts very well, with its O(N²) - O(N³) speed....

I implemented shelf packing, which under O(N log N), handles packing within seconds but is a clear degradation in quality.

I am currently looking into how I can combine the two... but this could take a bit of time to get right. Please hang tight :)

[gojushin]

In the long run, the only correct way to do this is probably to re-unwrap & bake the reduced parts. But that is likely out of scope here (and not really the point of the repo anyways).