Proposal: surface and portal navigation (including target surfaces) for Gen3

The current Gen1/Gen2 navigators have to deal with different (implicit) navigation streams:
* surfaces and portals from the geometry
* surfaces from external sources
* target surface(s)

The proposal is to make those streams for Gen3 explicit and base them onto the same implementation:

- a future navigator would be able to hold several (for the beginning fixed number) of navigation streams that all solve their respective navigation using shared logic & implementation: surface candidates are held by a navigation kernel that is updated by the stream until the navigation kernel is exhausted.
- these streams are processed by the navigator who then picks the closest solution of all streams and performs the associated navigation action
- the streams will have an explicit hierarchy otherwise, e.g. target stream overwrites geometry stream

The proposal would be the following 2-3 streams (and associated kernels):
- `target stream`: this stream holds the target surface(s) - this can be the final target surface, but also what was formally called `external surfaces`. The kernel of this stream is not really updated, just the tracing of the candidates internally is updated.

- `geometry stream`: this stream comes from the geometry and runs on a kernel (~ similar to what is now called the `NavigationState`) that is updated by the volumes navigation delegates (either during the stepping) and/or at portal passing.

Test, development sequence:
- [x] Write a `NavigationKernel` prototype (first w/o dependence on the stepper for multi-surface approach)
- [ ] Write a `StreamNavigator` prototype having two different streams
- [ ] Write extensive unit tests of standard and edge cases how such a navigator should behave
- [ ] Fill the `StreamNavigator` with two streams: sensitives and portals/boundaries from Gen1/Gen2 and demonstrate that correct navigation can be achieved
- [ ] Proof of concept

If/when proof of concept is achieved:
- [ ] change API of NavigationDelegates to fill `NavigationKernel` instead of `NavigationState` (or morph NavigationKernel into NavigationState)
- [ ] Run test on Gen2 ODD

*Watchpoints*:
- `target stream` should overwrite `geometry stream`, i.e. if a surface is in the `target stream` it should be ignored somehow in a the `geometry stream`: possible solution is to hand exclusion candidates to the delegate when updating the kernel (i.e. could be a kernel member)