[task]Switch to NavMesh Components

[francy51]

We should really switch to that, espec. because I plan to do Instances later on.

Note: We need navmesh for monsters etc. even if the character controller will/is physics based

[wovencode]

btw: not required until we get instancing

[DX4D]

Once this is implemented, sub-zones can bake navmesh dynamically so that we don't need to bake it into the parent zone, but there are a couple "gotchas" involved here:

-The server won't be able to dynamically load navmeshes because many players are going in and out of sub-zones and it can't load a unique navmesh for each one. We will need to investigate what happens when the server has a static navmesh where it loads all zones at startup but clients have a different navmesh - I'm assuming that the client's navmesh gets rejected - in which case this solution will not be appropriate in an "instances situation".

-This will still be useful in things like player building where objects are placed on the map for everyone to see (and not walk through), but all of the navmesh rebuilding needs to happen on the server (and probably Rpc'd to clients in proximity) the overhead involved will not be trivial - I don't think this belongs in the core

There are already great 3rd party building solutions like EBS (Easy Build System) that do this job already. I would not consider player building/housing a core feature, so it should be an addon/module/integration. Once we have an interaction and item system in place, the EBS author will work with us to create an integration (I worked with them to do the usurvival integration when that first came out)