Add revision to the generated navmesh

[elsid]

While changes like #657 fix issues with generated navmesh they also change the output for given input so for any caching system it might be a problem to detect such a change. This is a problem because users keep the old revision of the data even if they use newer version of the library and can still get undesired behaviour like crashes until they regenerate it. Would you consider adding a navmesh revision to the generated data and increment it every time there is functional change in the navmesh generation? Also return current revision from a function with stable ABI so it's possible to compare navmesh data revision with currently provided by the library for automatic cache invalidation. Stable ABI is important since on Linux distributions it's possible to have different versions of the library dynamically linked to a binary.

[grahamboree]

Yeah this is a good idea I think. The original expectation with Recast and Detour was that people integrated it into their own custom engine and systems which handled all this, and the versions provided were mostly an example or to support RecastDemo. That's not universally the case, though, and we've seen some people rely or build on RecastDemo to be their navmesh-authoring tool.

It'd be nice to have versioning in the binary data to handle cases like this. It does also mean we should consider data migration logic for binary data, since people are saving navmeshes in older versions and trying to load them in newer versions.