* update author's name after recent rebranding of Eficent to ForgeFlow.
* change license to lgpl as agreed by the authors.
* update readme to new format.
The computation of the unreserved available amount using the
StockQuant._get_available_quantity was wrong as soon as more than one
quant was found for the same product. It can easily happen when you have
sublocations and a quant in each location.
The reason is that the algorithm was:
1. searching for all the quants for a given product
2. calling StockQuant._get_available_quantity for each quant
3. _get_available_quantity is an @api.model method, which itself will
search for all quants for the product and the given location and
children
Which means that if you have these locations:
Stock
Stock > Bin A
Stock > Bin B
And these quants:
1. Product: Product A
Location: Bin A
Quantity: 60
Reserved: 0
2. Product: Product A
Location: Bin B
Quantity: 10
Reserved: 0
Instead of 70, the result was 140. (One loop for each quant, each loop
recomputing the total quantity in _get_available_quantity, all summed
togethed, for each new quant, an additional sum would be added).
Ultimately, the _get_available_quantity method does the sum of (quantity
- quantity reserved). This commit uses the same logic than the 10.0
branch, it finds the quants contextually using
ProductProduct._get_domain_locations and get the available quantity as
the sum of (quantity - quantity reserved).
We can't really use StockQuant._get_available_quantity because this one
expects a location, while here we don't necessarily know it.
I removed _product_available_not_res_hook which seems to have no
purpose, it does not receive the result of the computation and its own
result is unused.
