Add meta class to handle config saving

[AMHermansen]

Currently we're using a decorator around every __init__ of classes that inherits from Model/Dataset. This creates redundant boilerplate code. This PR aims to introduce a new way of handling the backend config saving. This is done by creating metaclasses responsible for intercepting the objects created and store a corresponding config dict to the created objects.

The following is done:

1. Create relevant metaclasses (ModelConfigSaverMeta, DatasetConfigSaverMeta) along with common interfaces between these metaclasses and ABCMeta.
2. Remove usage of save_model_config and save_dataset_config and add deprecation warnings when they're used in code.

This means the config saving is purely done in the backend, away from any frontend users, making the code easier to read and avoids potential slip-ups where one might forget to use @save_model_config.

This PR currently introduces a bug. I suspect the bug is a conflict with #584.

Could you maybe try to take a look at this @RasmusOrsoe

[AMHermansen]

Previously mentioned bug was resolved by #593, wasn't an issue with this PR.

[AMHermansen]

mypy is only failing for code, which wasn't modified by this PR.
I believe the source of this, is that the decorator save_model_configs alters the expected argument types for __init__ to be *args: Any, **kwargs: Any. Which means all __init__ functions trivially passes the mypy test. Fixing those seems out of scope for this PR, and should probably be adressed in a separate PR (possibly before merging this).

[RasmusOrsoe]

@AMHermansen Let's take a look at this together after the dev meeting, if you have time.

[AMHermansen]

@RasmusOrsoe I've now changed the typehints from the source code, that was conflicting with mypy (except for the SQLitePertubedDataset). This means that currently it is only the examples which are failing for mypy, feel free to have a look at this PR when you get the time 😄 .