Refactor: Rocky KATalogus clients

[Donnype]

          Some APIs of those clients are not organization-specific though, and hence forcing an organization as a property of the API client becomes a bit ugly. I believe this client is not the place to force handing over the organization as that makes the clients do to much and make them not reusable in context where we should have full access, such as with the runner. To have a nice layered design, we could introduce a layer where we properly manage access, such as a new client class that can only call organization specific methods of the base client.

Originally posted by @Donnype in #3666 (comment)

[underdarknl]

I'd propose to split the client into two classes.
The base class that handles generic (eg, non orga or user bound) requests, which can be initiated without providing the organization code. This layer could also handle most generic functonality (session building, http requests as a private method) of the expected exceptions (eg, timeouts, connection errors) and streamline them into Exception classes that subclass from the Generic KatalogusException or BytesException.

The second class subclasses from this first class and adds the organization or user arguments to the init. It also adds the specific methods that only work when an organzation or client is required. This layer also adds permission checks if needed, and the needed exceptions. (eg, dot bleed a rw http 404 or http 403 back to the user but instead throw something like a KatalogusPermissionDenied or KatalogusObjectNotFound error. (which can be subclassed from the KatalogusException AND the generic objectNotfoud classes available in Django. This helps catching these exceptions everywhere upstream.