Clean up Drupal\jsonapi\Configuration\Resource(Config|Manager)(Interface) [#2829740]

The name suggests this contains value objects and/or logic for the configuration system. The class names suggest this too. But that's not the case.
The docblock at \Drupal\jsonapi\Configuration\ResourceConfig says
```
 * This object contains all the information needed to generate all the routes
 * associated with a JSON API type. In the future this is going to be
 * constructed (maybe?) from a configuration entity.
```
But I don't think that is good enough. At #2829398: Clean up JsonApiResource: the annotation, plugin type, plugin manager, plugin implementations, the dynamic routes generator and the request handler, I've already pointed out confusion wrt configuration/configurability in the plugin annotation/plugin code. This only adds to the confusion. I think that this needs to be addressed now. In the current state, it will not be possible to allow configuration of any JSON API Resource.
\Drupal\jsonapi\Configuration\ResourceManager(Interface) shows further entanglement of the JSON API module's design with entities, like I already described in #2829398: Clean up JsonApiResource: the annotation, plugin type, plugin manager, plugin implementations, the dynamic routes generator and the request handler: The 'entityType' key. This limits JSON API to data stored in entities. Either that's intentional, and we can just remove JSON API plugins altogether (and generate routes directly etc), or we must remove this key. — everything here points further in that direction. Again, that's fine. But then we should make JSON API entirely about entities, and we can remove the plugins altogether.
Overall, it seems that all code in the Drupal\jsonapi\Configuration namespace is about mapping entity type/bundle "configuration" (it's largely code, with some bits of configuration, but you never directly interact with config as in \Drupal\Core\Config\Config or ConfigEntity objects) to JSON API "configuration" (which is really just data structured in memory, generated at run time, with a hook_jsonapi_resources_alter() hook to allow modules to alter stuff). In other words
Finally, \Drupal\jsonapi\Plugin\Deriver\BundleDeriver::getDerivativeDefinitions heavily relies on \Drupal\jsonapi\Configuration\ResourceManager's logic, which in turn heavily relies on entity type/bundle metadata.
Combined with the fact that there is only a single @JsonApiResource plugin implementation which has zero logic, this suggests to me that you very much wanted to keep the door open for
1. exposing things other than entities via JSON API, but now the time has come to wonder whether that's truly worth all the additional complexity? (Not to mention it wouldn't integrate with all the other infrastructure, which relies on entities/fields/entity reference fields/….)
2. alter hook-based overridability/configurability — which arguably could just happen in a \Drupal\Core\Routing\RoutingEvents::ALTER subscriber