[breaking] - NavMeshSettings refactor

[aclegg3]

Motivation and Context

Several recent needs have exposed the brittleness of current NavMesh defaults for Simulator reconfiguration. This PR aims to provide much more flexibility in configuration and reduce unnecessary compute while remaining simple for default use-cases.

This is a breaking change.

Currently, when a Simulator is initialized, the default agent radius and height are used to trigger a re-compute of the NavMesh if any other settings are modified. This cannot be turned off and other settings cannot be modified without explicitly recomputing again after instantiation which can be costly in aggregate and occasionally block use-ability altogether (e.g. if some property of the stage causes navmesh computation to fail).

After this change:

1. An optional NavMeshSettings object is added to SimulatorConfiguration. This can be configured by user code before the Simulator is instantiated and will trigger NavMesh re-computation as necessary. If omitted, the NavMesh will not be constructed (however, the scene may still load one from file).
2. The option to include RigidObjects with MotionType STATIC has been migrated into NavMeshSettings to unify the API and eliminate the need for variable chains to configure this feature.
3. Backwards compatible default behavior (agent specific default NavMesh re-computation) is now realized through and configurable in utils.settings.py. (NOTE this API documentation is not updated until the PR is merged, see the file changes for details).
4. (breaking deprication) Any automated search for navmeshes matching a specific raw asset has been removed from Simulator.py. This is outdated and should be done in configuration files or the stage loader rather than shunted into the initialization step.

Habitat-lab will need to be updated to use the new API. facebookresearch/habitat-lab#1351

Should cover the needs of #2104.

How Has This Been Tested

Updated tests should cover this.
I did additional local testing with python viewer to double check.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have completed my CLA (see CONTRIBUTING)
• I have added tests to cover my changes.
• All new and existing tests passed.

[jturner65]

LGTM

[0mdc]

LGTM! I left some minor remarks.

[0mdc]

This should probably be forward-declared as this class is widely used.

[aclegg3]

Yeah, I thought so too. However, the compiler does not like the forward declaration here, so I needed the full the include.