Mesh sizing without physical groups

[hughcars]

This PR removes the need for PhysicalGroups specifying the mesh size field, which is a prerequisite for fragmentless construction. This is achieved by interrogating the occ kernel directly for line segment coordinates, and collecting the resulting points for use in a KD tree later. This has a few upsides:

1. Fewer entities in the model speeds up boolean operations (notably intersect and fragment)
2. The size field can be modified after rendering, without needing to rerender the model. This allows for a single SolidModel render to be used to generate multiple meshes, a better separation of concerns compared to the previous approach.
3. Utilizes a KDTree for a callback sizing function, which provides a size field with very fast evaluation.
4. Additional sizing points can be manually added in after the rendering. For instance if a user decides a particular location is problematic, they can manually insert a control point and refine there.
5. Given multiple meshes can be generated from a single SolidModel render, if a meshing operation fails, a second attempt can be made in the same workspace without requiring re-rendering.

This also deprecated MeshingParameters as the specification of the meshing parameters is now decoupled from the call to render!. Additionally this adds in the Geometry.OCCParallel parameter, which in theory speeds up boolean operations by utilizing threads available, I haven't seen much of an impact from this however.

One possible extension would be the ability to generate a set of control points from a schematic graph, without requiring a re-render. This would mean hoisting the control point calculation out of open cascade entirely however, so is not done for now, as that entails a meaningful increase in complexity to interrogate any given line segment or entity.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[gpeairs]

This looks very nice, just a couple documentation comments. Was there more testing you wanted to do before merging?

[gpeairs]

I think I would phrase this differently. If I understand right, isn't mesh_scale is more like "where does the mesh size bottom out near each meshsized boundary"? Or in other words the grading everywhere still looks as though you used h (and in particular the size field remains identical beyond the original h), it's just that the size starts at mesh_scale * h rather than h.

[hughcars]

That's exactly correct. It makes the size field smaller right next to the entity, but does nothing further away. We had the discussion about introducing another parameter to do a "uniform refinement" style operation, which does more refinement next to the entity, but also refines further away. I'm all ears for better names for these too.

[gpeairs]

I'm not sure where, but I think all these mesh size related functions should link to a canonical docstring with the mesh size field formula. I think only MeshSized and meshsized_entity have the formula in their docstrings right now.

[hughcars]

That's a good idea, I can add a link to MeshSized very easily and then put everything there. The links can then be both ways, with all the control functions linked from there too. Ought to help with usability a good bit.

[hughcars]

This looks very nice, just a couple documentation comments. Was there more testing you wanted to do before merging?

I'm attempting to test this (and the follow up restrict removal PR) on some more designs coming from @ybrightye amongst others. Not seen any real issues so far, and generally the improved performance stands. However, given this is effectively gutting the mechanism by which meshing is controlled, I think more testing would be good, if I can find anyone to volunteer as tribute.

[hughcars]

Rebased on main, and fixed some documentation up in 4f02a37