Engine: Add runtime navmesh generation

[zach2good]

I affirm:

• I understand that if I do not agree to the following points by completing the checkboxes my PR will be ignored.
• I understand I should leave resolving conversations to the LandSandBoat team so that reviewers won't miss what was said.
• I have read and understood the Contributing Guide and the Code of Conduct.
• I have tested my code and the things my code has changed since the last commit in the PR and will test after any later commits.

What does this pull request do?

Given that Ino has done god's work with ximeshes and xi-visualizer, sruon added ximesh loading to LSB, and the RecastDemo shows you how to generate nav data from 3D point/tri data... why don't we just make xi_map capable of generating it's own navmeshes?

By default, the system remains as it has always been: if the file is in /navmeshes/, use it. If it isn't there, it'll use the corresponding ximeshes entry and generate a new navmesh file using the defaults we used in the xiNavmeshes repo.

The defaults are the same as before, so this doesn't FIX any foibles with navmeshes yet

But, this opens up the doors to test and experiment and actually know what the different numbers do, and try to capture test cases and get things like Garlaige Citadel or the high walkways in Sky to behave better.

THIS ALSO DOESN'T FIX PATHFINDING - Both navmesh and pathfinding are borked, and both need to be working for a smooth experience.

Tracy

I did a little experimenting of dropping cellSize and cellHeight down, and it does seem to give a 5% boost in performance, at the cost of doubling (or more) the size and memory footprint of the navmesh. Interesting stuff.