Miscelaneous changes from MeshClipper development

[gunney1]

Summary

These are some small changes that didn't fit anywhere when I was breaking the big MeshClipper code review into small pieces.

1. Preserve the allocator id user had set on an output Array. MeshClipping code should respect what allocators the users want to use.
2. Robustly handle conflict between blueprint and mint over whether a "fields" node is required when there's no field stored.
3. Clarify that some input data should be in host memory.

[Arlie-Capps]

Thank you for these fixes, @gunney1 .

[Arlie-Capps]

Brian, why isn't develop the target for this MR?

[gunney1]

Brian, why isn't develop the target for this MR?

Just following the pattern that worked well when I was splitting up the mesh clipping work. I guess it could work just as well to merge into develop, but I think there's some dependencies that might bring in un-related changes.

[Arlie-Capps]

Brian, why isn't develop the target for this MR?

Just following the pattern that worked well when I was splitting up the mesh clipping work. I guess it could work just as well to merge into develop, but I think there's some dependencies that might bring in un-related changes.

I see: thank you for the explanation. I'm interested in reviewing changes once only, which is why I would prefer targeting develop. If others on the team have opinions on this, I'd be interested to read them.

[gunney1]

Brian, why isn't develop the target for this MR?

Just following the pattern that worked well when I was splitting up the mesh clipping work. I guess it could work just as well to merge into develop, but I think there's some dependencies that might bring in un-related changes.

I see: thank you for the explanation. I'm interested in reviewing changes once only, which is why I would prefer targeting develop. If others on the team have opinions on this, I'd be interested to read them.

I think you would not have to review the same code twice this way, unless the review required some radical changes. I don't think that will be the case here. When we have change B dependent on change A, we probably don't want to set both of them to merge into develop, because B's changes must also include A's, and you'd see A's changes twice.