Junction restrictions hook

[Elesbaan70]

Resolves #902

An IJunctionRestrictionsHook API implementing the idea discussed in #1557.

I had originally planned make this change before beginning the optimization/reorg of JunctionRestrictionsManager, but it turned out that I had to do most of that work in conjunction with this. But all the redundancies can't finally be eliminated until the patches are gone from the stable builds of NC2 and NCR.

Relevant PRs for the Node Controller projects: https://github.com/MacSergey/NodeController30/pull/55 https://github.com/kianzarrin/NodeController/pull/33

[Elesbaan70]

This is basically done now, but I want to get NCR working before taking it out of draft status.

[Elesbaan70]

I had originally planned make this change before beginning the optimization/reorg of JunctionRestrictionsManager, but it turned out that I had to do most of that work in conjunction with this. But all the redundancies can't finally be eliminated until the patches are gone from the stable builds of NC2 and NCR.

[krzychu124]

Solve conflicts and sync with master? 😅

[Elesbaan70]

We need to determine the correct resolution to the duplication of @kianzarrin's JunctionRestrictionFlags and my JunctionRestrictionsFlags before this can be merged.

[Elesbaan70]

The number of external mods patching junction restrictions is increasing. This really needs to get merged.

[Elesbaan70]

The end objectives here were:

1. Simplify the Junction Restrictions API
2. Cache Junction Restrictions calculations to improve the efficiency of pathfinding

The ordinary way to do this would be to make a new cached API, and have the existing methods call the new ones. Unfortunately, this could not be done straightforwardly, because the API methods are being patched by Node Controller, and now also by Adaptive Networks. The conventional approach would leave the new API methods unaffected by the patches, breaking those mods.

Therefore, the following strategy is being followed:

1. Phase 1: Caching and Hooks API
   1. Re-implement the patched API methods as privately implemented interface methods so that the patch is no longer altering the API entry points. These still call the existing patched methods so that the patches continue to work.
   2. Create a caching layer between the new API and the patched methods.
   3. Introduce a "hooks" API that will allow external mods to alter Junction Restrictions behavior without patching.
   4. Release to stable.
2. Phase 2: External mods change over to the hooks API and release to stable.
3. Phase 3: We remove the extra patched method layer, simplifying and cleaning up the final implementation.

This PR represents Phase 1.

[Elesbaan70]

Since most of the TMPE implementation was calling the API methods directly via JunctionRestrictionsManager instead of through its interface, they all had to be updated when the deprecated API was changed to privately implemented interface methods. This was necessary because the methods they were calling are now an uncached implementation detail, and are not guaranteed to work correctly if called from outside.

This means that a lot of files were changed. Following is a list of the files with functional changes. All other changes are refactoring and eliminating deprecated API calls.

API Declaration and Instantiation

TLM/TLM/Constants.cs TLM/TLM/Hook/Impl/HookFactory.cs TLM/TMPE.API/Hook/IHookFactory.cs TLM/TMPE.API/Hook/IJunctionRestrictionsHook.cs TLM/TMPE.API/Implementations.cs TLM/TMPE.API/Manager/IJunctionRestrictionsManager.cs

JunctionRestrictionsManager changes

TLM/TLM/Manager/Impl/JunctionRestrictionsManager.cs

Rename a deprecated class to avoid confusion.

TLM/TLM/Geometry/Impl/SegmentEndIdApi.cs TLM/TLM/Network/Data/SegmentEndId.cs TLM/TLM/Util/Extensions/SegmentEndIdExtensions.cs