Modularisation of Oak

Epic to track individual steps towards improved modularisation of Oak

Until now Oak modules are all released together, which has some drawbacks. Work on the modules must be somewhat kept in lockstep. Releasing a fix for a module means all other modules must be in a state that can be released as well. For a user it may be desirable to just update a single module to get a fix and not a complete set of Oak bundles.

The general approach for this epic should be to modularize only as needed and not split everything. Obvious candidates are stable interfaces like Oak and NodeStore API and NodeStore implementations.

This requires fixing potential circular dependencies between logical modules we want to split up. We need a better distinction between the interface part of the SPI and its implementations. Utilities and commons code must be reviewed and potentially moved.

The oak-it related dependencies should be reconsidered and that a development version of a NodeStore implementation can run integration tests. With the current dependency setup a release of the NodeStore implementation is required first to run the integration tests with those changes.

Some modules will probably be moved to the top-level and have their own branches and tags.

To avoid branches it is important to always have trunk stable. Feature work must happen on feature branches, in a forked module or protected with a feature flag until it is ready for prime time. No more unstable work in trunk.

Module owner is primarily responsible for module releases. At some point there won't be a dedicated person anymore responsible for 'the Oak release'.