Based on #615, this feature allows specifying price sensors per device, flexible or unflexible.

In the flex-contextparameter, we already have consumption-price-sensor and production-price-sensor. They will remain the default (see https://flexmeasures.readthedocs.io/en/latest/api/notation.html#flex-context).

New parameters consumption-price-sensors-per-device and production-price-sensors-per-device can optionally be added to overwrite this default, so that some devices are priced by other price sensors. These parameters are dicts, mapping the power sensor IDs of devices (assets) to price sensor IDs.

TODO:

• Adapt FlexContextSchema (in data.schemas.scheduling.__init__.py). This should suffice to make the API parse these new parameters and pass them on.
• Also add these parameters to the CLI command flexmeasures add schedule for-storage (in cli/data_add.py), so they end up in flex_context (line 1054ff). This should help with testing locally.
• Get prices for these distinct price sensors from the database in data.models.planning.storage.py::StorageScheduler.compute_schedule() (also add the price slope trick for these) and pass them on to device_scheduler(). I'd say we keep them as a dict until here
• In device_scheduler, we need to adapt the model so that per device (denoted by "d" in the ConcreteModel), the correct price is applied. I believe the best places are price_down_select() and price_up_select().
• Add a scheduling unit test. Idea: In data.models.planning.test_solver.py::test_building_solver_day_2(), we could add a market_scenario parameter for the case that the price for solar (feed-in tariff) is much higher than the tariff used by the battery (the default). Then we can expect the battery to never charge. The pytest fixture create_test_tariffs might be a good place to add the extra price sensor and data.
• Add documentation for the new parameters, in the flex context description.
• Bonus: Adding an integration test with the API (api.v3_0.tests.test_sensor_schedules.py), which is crucial for the actual operation. However, the existing tests are not including the flex context a lot, anyway, so I can't demand it from you now.