Support external customisation of top-level namespace

What

Support build system customisable top-level namespace(s) of all OpenAssetIO symbols.

Why

There are use cases where multiple (incompatible) copies of OpenAssetIO may coexist in a single application process.

For example, an OpenAssetIO Host application may have its own plugin system, and an application-specific plugin may wish to (privately) make use of a custom build of OpenAssetIO as well as the version exposed by the host application.

Acceptance Criteria

Delete as appropriate based on requirements gathering:

• Expose the existing inline namespace macro OPENASSETIO_CORE_ABI_VERSION as a CMake cache variable.
• Add a new inline namespace wrapper around all symbols, and expose as a new CMake cache variable.
• Add a CMake cache variable to enable renaming of the top-level namespace openassetio.
• Encode the customisable namespace(s) in the file names of the binary shared libraries.
• Mirror the customisable namespace(s) in Python (see Python namespace packages)

Notes

Needs requirements gathering to narrow the focus.

Start by reviewing the CMake configuration, C++ namespace declarations, shared-library naming, and Python packaging relevant to OpenAssetIO symbols. Gather requirements for which namespace customisations are needed and whether they must be mirrored across C++ binaries and Python packages. Done means the acceptance criteria are narrowed to a decided, testable scope.