Remove obsolete data classes

[Flix6x]

This is the big one.

• Update conftests to set up only the new data classes (GenericAsset, Sensor and TimedBelief)
• Update tests accordingly
• Remove Power
• Remove Price
• Remove Weather
• Remove TimedValue (on which Power, Price and Weather are based)
• Remove Asset
• Remove Market
• Remove WeatherSensor
• Remove AssetType
• Remove MarketType
• Remove WeatherSensorType
• Remove schemas associated with obsolete classes (mostly in api/common/utils/validators.py; I left a few decorators with salvageable code/ideas, mainly regarding ISO8601 durations, that could be helpful in improving our Marshmallow schemas/fields)
• Remove Resource
• Remove query support for (already previously removed) analytics view
• Remove query support for (already previously removed) portfolio view
• Remove util functions dealing with obsolete classes
• Check code for mentions of deprecations
• Remove documentation references to obsolete classes (I couldn't find any)
• Update documentation notes on data model transition (@nhoening probably you want to have another pass at this)
• Sunset the fm0 scheme for entity addresses

Follow-up issues created:

• Database migration removing the obsolete tables (worth a short discussion first on how this should be handled) Data migration after removing obsolete data classes #875 875
• Check whether documentation section on singular/plural keys can be removed
• Sorting RESTful index endpoints
• Interpretation of DurationField as a timedelta by taking into account a corresponding AwareDatetimeField (see api/common/utils/validators.py)
• Document special interpretation of generic_asset_type_name="weather station" in data.models.forecasting.model_spec_factory (it could also become a configuration setting)

[nhoening]

A bit disappointing that coverage only improved by 1% :(

There is a function called new_decorator which now is uncovered. Maybe it is not used anymore?

[nhoening]

Very satisfying to read (and also a bit nostalgic!)
Great work !

Some broader comments:

• This PR should also have a data migration (removing structure)
• The documentation still talks about "portfolio", "analytics" and "control" (there is even a page for each of them in the views folder, but also look at concepts/benefits_of_flex.rst and host/modes.rst and configuration.rst). There are also mentions in ui/templates/base.html

[Flix6x]

The data migration is still a sizable task. Running flexmeasures db migrate generates a very large auto revision file (~200 lines) that needs to be checked manually. These predominantly deal with the downgrade.

There is also the offchance that the deleted tables contain user data that has not been migrated yet. This should only be possible in case data was added by circumventing our own classes (e.g. initializing an Asset has been leading to initialize a GenericAsset and a Sensor under the hood). However, I can't guarantee that simply removing the old tables wouldn't lead to some loss of data. Therefore, I suggest creating backups of the deleted tables.

Foreseeing this exact discussion, I had moved the database migration into the list of follow-up tasks to this PR (see task list above).

[nhoening]

Great stuff!

A thought on the data model migration: We could add a warning if we find data (e.g. >0 assets and/or sensor and/pr Power data). Didn't we have a confirmation dialogue in one of the other migrations? It would not affect users who have no such data.

Does a db upgrade call actually work on an empty database, given that the data classes are not there anymore? I believe we stopped using the classes in migrations (I did a quick check).