WIP: Make Quantity an abstract base class

[llucax]

This is a draft PR just to make sure there are no big objections to moving forward with the idea.

The draft is there mostly to show how the new quantity and SupportFloatT is used, the _quantities module in particular has a lot of noise, so it shouldn't be reviewed in detail.

The code in this PR passes mypy and flake8 checks on src, but not in tests or benchmarks, as these are not updated yet.

The most important things to note are:

• It uses SupportFloatT as a TypeVar bound to SupportsFloat to allow Sample and most other types working with either float or Quantities to be used.

• This means for the generic types needing to actually use the underlaying value, we sometimes need an extra conversion to float when some operation is needed. This only happens in Sample3Phase to get the max/min, and the resampling function. It happens also implicitly when checking for NaN of infinity.

• Added a value constructor to the resampler to be able to produce new samples. This has the nice side effect that if you need to resample something that you know is in, say, kW instead of W, you can use Power.from_kilowatts as the constructor.

• There are quite a few (unfinished) fixes/improvements to Quantity and its sub types. The most important changes to Quantity are:

  • The trick to disable the default constructor was replaced by a more straightforward implementation in the __init__ and the utility _new method is added to create instances.
  • The .base_value was replaced by __float__, as this was only exposed to be able to work with a Quantity as if it was an unknown float.
  • QuantityT is not needed anymore and removed.
  • Quantity is now an ABC.
  • The _base_value is moved to the constructor, to have better rendering for the docs.
  • Removed isnan() and isinf() as now the math functions can be used directly instead (maybe we can keep them for convenience).
  • There are some random migrations to match instead of if, which needs to be cleaned up.

Of course once this have a rough approval, I'll split in smaller commits (and even PRs) and update tests and docs.

Fixes #821.

[llucax]

When fixing the tests I bumped into an issue that might be tricky to solve.

If I understand correctly, all the FormulaEngine stuff is parametrized on a QuantityT mainly because of the high level formula engine, which allows to create formulas from formulas.

So far it seems like there is a lot of code and complexity to deal with QuantityT, which can be a Quantity or float, or even 3-phase stuff. For what I've seen these classes also don't differentiate very well between the input and output type, and these are usually mixed (one QuantityT TypeVar parameter for both things, which can resolve to Quantity and thus have a different type for the input and output, but the class is then specialized with Quantity, not the specific subclass).

As it is taking me a quite a bit of time trying to understand all the formula engine stuff, in particular when thinking about input and output types, I will delay the work on this PR.

It is not very clear to me which stuff should work with float and which should use quantities. For example, the evaluation is all done with plain floats by the FormulaEvaluator, which also means that if we are mixing different types.

We need to make sure to use the base_value in a way that is compatible, in particular for multiplication (like current * voltage). In this sense I think we might need to have a more explicit definition that base_values are stored in the base SI unit or something like that, so we can operate on them safely as pure floats.

To progress with this PR I will probably add a second parameter for formula engine stuff that could have a different input and output type, so we have something like InputT and OutputT.

[llucax]

I thought that maybe to reduce the complexity of this formula engine stuff we could pin the type to float and consider it a low-level construct, and only convert to a quantity after a value is retrieved from a formula engine, but I guess this won't work.

The problem is formula engines are really "leaked" to the user, so users can do (microgrid.grid.power + microgrid.pv.power).new_receiver() and it would be bad if that receiver just gets floats, it would mean users will need to convert to Power manually which kills the built-in safety we have now. :(

I guess this is also a shame in terms of performance as we might have a lot of conversion going on inside the pipeline that is not strictly necessary.

Not sure if there is a way to have all the internal formula engine stuff working with floats and only convert to quantity when leaving the engine, I guess we would have to put (a lot) more thought into it to find out.

[llucax]

FYI, I cleaned up this PR a bit, it is still a WIP, but except from the commits with WIP in it, they should be much more readable and give a much better idea of what the intention of this PR is and how things are supposed to work.