Normalize `*Strategy*` related classes and properties

[Carsopre]

Kind of request

Changing existing functionality

Enhancement Description

We want to have self-contained and self-explanatory dataclasses whose purpose is defined (and limited) during the koswat analysis.

During the last PRs we have introduced (at least) the following dataclasses for strategy calculations:

• StrategyInput, (should be) used as an input to generate the results.
• StrategyLocationInput (should be) used as the initial state of a location (selected reinforcement, costs, ...)
• StrategyReinforcementTypeCosts (should be) used to store the location's costs for a specific reinforcement type.
• StrategyLocationReinforcement (should be) used to represent the resulting state of applying a strategy.

On the other hand, we also should consider the renaming of OrderStrategy into something related to its real scope (clustering based on space due to obstacles)

• Study the option to change the return type of StrategyProtocol.apply_strategy to return an object that also includes the used reinforcement order.

What needs to be done?

Create sub-tasks for better traceability!

• [ ] Streamline the scope of the aforementioned dataclasses, creating new ones if needed ( StrategyObastacleCosts / StrategyLocationInfrastructureCosts?).
• [ ] Ensure the (class and properties) names match expectations.
• [ ] Define strategies' scope as docstrings and rename if necessary.

Use case

• Code should be readable and easy to extend.
• Objects should have a defined limited "life" scope.
• It can be confusing when the names seem to be the same.

Additional Context

Do not take this issue during active development of strategies.

[ArdtK]

@Carsopre I also spotted a few other (broader) opportunities:

• measure vs reinforcement vs reinforcement profile vs profile
• cost vs costs