Migrate Storage to its own Eesyplan component

[Bachibouzouk]

This Migration should be perfomed last as it alters the dto to MVS

This PR shall list the important steps and contain remarks useful to perform the migration

Each storage component has some parameters within its 3 children "capacity", "charging_power" and "discharging_power". We would like to get rid of this unnecessary complexity and of the parent_asset field altogether. One must be careful in the order of the migrations and especially how the field of the children are to be used within the eesyplan component form and field values. Source of information are to be found in handle_storage_unit_form_post fonction, as well as witin convert_to_dto (looking for the keyword "ess"). The dto fonctionnality will be broken if we get rid of the children asset and replace the MVS storage (which consists of one GenericStorage an internal Bus and a Charge,Discharge Converter). Normally the Charge and Discharge Converters have conversion_factors set to one and could be discarded.

The fields such as crate should be removed from the Asset Model and added to the Storage Model, while preserving the saved values within the database

Currently this PR is only creating new models and populating them with the relevant values taken from the old Assets (collection of children assets). The ability to send a MVS simulation is therefore broken as there is no more 3 child to a storage component and the dtos will fail.

Once we are confident we have all the necessary data from the storage, this PR will help remove a lot of code lines by dropping StorageForm usage and special treatment of storage assets to always bookkeep their children. Thus making the code easier to understand.

I think we were already mostly using the values within the "capacity" child, but I am not 100% sure anymore.

[paulapreuss]

Nice job on this!

I tested around a bit and the migrations look to be working well. I had problems with the to dto on the storage assets - see the two commits I pushed.

We will have to be very careful about what is all impacted by these changes also after we remove MVS - for instance we need to make sure to migrate all fixtures and existing use cases to the new structure, and check for any floating hard coded attributes. I am also not quite sure I fully understand how the storage hierarchy was working before.

[Bachibouzouk]

@paulapreuss - now I made the new storage component back compatible with MVS by modifying the dto of the storage.

I noticed that the "maximum capacity" and "optimize capacity" fields were not visible in the new model form, but that the "dispatchable" field was visible although it should not, I will fix that later