--Bug fixes: Navmesh building and reconfigure in viewer.py

[jturner65]

Motivation and Context

This small PR fixes 2 bugs :

• Viewer.py : Update the locally maintained scene name to be the unique, minimal, name of the currently loaded scene. This is necessary if the user requested a scene by some non-unique substring of a scene name (in which case the first match would be the scene rendered)
• Do not build a navmesh on a joined collision mesh devoid of vertices. If this is attempted, the process will assert. Reviewers, please share if you feel this is the appropriate response.

How Has This Been Tested

Locally all python and c++ tests pass

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]

Do we want to have this assert if the joinedMesh is empty? Or just fail? This will probably not occur often - would primarily happen if someone attempts to build a navmesh on the NONE scene, so just failing without the assertion would probably be fine, but I am not sure if there are possible situations where an assertion would be best (i.e. training and somehow an expected collision mesh is empty).

[jturner65]

...or is it better to have ESP_CHECK for this, which will throw in python and can be trapped in a try if necessary.

[aclegg3]

I like this approach, thanks for adding this check. I've seen the resulting issue a couple times and the current crash message response is non-obvious.

[aclegg3]

LGTM