Restructure the inspector API

[Neverlord]

We currently have various inspector in the CAF main namespace:

• json_reader
• json_writer
• stringification_inspector
• ...

To at least get the implementations details out of the public headers, we moved to a PIMPL-based approach. However, this is a one-off in CAF. We generally move towards interfaces in the public API and the factory pattern to avoid having to expose implementation details at all. Implementations should move into the internal or detail namespace (or an anonymous namespace as implementation detail of the factory).

For CAF 2.0, we should get our inspector consistent with the overall design:

• add a new namespace for our inspectors
• add the interfaces for out inspectors to that namespace
• provide factory functions to get instances of the inspectors
• re-implement and deprecate the current set of classes
• remove the fast_pimpl class again

[Neverlord]

We could also consider leaving the pimpl-design as-is with a few tweaks:

• get rid of the inheritance hierarchy for the user-facing types like json_reader
• offer an as_serializer / as_deserializer getter on the facade types instead
• push the current completely private implementations to the internal namespace

That way, we still get a clean separation of public and private API, allowing us to make tweaks to the implementations without breaking the ABI. Users can still write their custom serializers / deserializers if they really want to since those two interfaces remain public. However, users won't be able to inherit from the json_reader for example. I think that's a reasonably tradeoff. Pushing more classes into the internal namespace gives us more flexibility and reduces the overall API surface.

[Neverlord]

We currently have on the public API:

• binary_serializer
• binary_deserializer
• json_writer
• json_reader

With matching interface types:

• byte_writer
• byte_reader
• text_writer
• text_reader

We already use the PIMPL idiom with our new placement_ptr-based design. However, having the interface types on the "outer" types doesn't make that much sense. For example, json_writer extends text_writer but only dispatches to the opaque implementation type.

Instead, we can change the type of the placement_ptr and then inline all calls on the outer type. So for the json_writer: don't extend text_writer directly but refactor it to have a placement_ptr<text_writer> impl_ member variable and then use inline member functions for all of the value overloads to call impl_->value(...). Plus a new as_serializer() getter that we can pass to a meta_object (or in other places where we need to code against a specific interface).