Purpose
=======
This commit introduces the notion of taxes and fiscal position in
subscription models.

This change was motivated by the fact that you cannot currently properly
manage taxes on subscriptions: if you are not in the default case where
your subscription is supposed to use the default taxes from a product
with the default fiscal position of the partner, you're out of luck.
Unlike sale, purchase, account, etc. where you can override the
defaults - this was a serious limitation. In addition, this change was also
motivated by the fact that the integration with TaxCloud of the
subscription module was hastily put together to counteract some nasty
side-effects (e.g. a payment is done in automated processing mode but
upon validation of the invoice, taxes sent by taxcloud change - the
amount you just authorized on the payment method no longer matches the
invoice you're trying to pay).

Specifications
==============
For consistency across modules, this borrows most of the logic from the
sale module.

- `sale.subscription.line` gets a m2m tax field as well as stored
computed fields for untaxed, taxed and total prices
- `sale.subscription` gets a fiscal position as well as stored computed
fields for untaxed, taxed and total prices
- taxes and fiscal position are forwarded from the initial SO upon
creation *AND* upon renewal and upsell
- taxes and fiscal position are forward upon invoice generation

Migration Strategy
==================
1/ Add *default taxes* based on the product and partner (*do not* try to
guess the taxes from the initial SO - existing subscriptions have been
generating invoices with the default taxes prior to this, making this a
mandatory choice for the migration)
2/ Recompute totals for lines
This recomputation should not be done in SQL, since it is based on taxes
that could be included or excluded, fiscal position mapping, currency
rounding and the like. Use Python code to do this. A possible strategy
to improve perfs should we need to (although I do not expect a lot of
database with *millions* of subscriptions to actually exist) is similar
to what we did in v12 for `pos.order.line` - categorizing all lines
according to a unique set of properties that entirely define the tax and
totals computations, compute totals for one sample line and push the
result on the whole set.
3/ Recompute totals for subscriptions
Quite simple since all underlying data was computed in the previous
step, unless round globally is active in the db, can most probably be
summed in SQL from the lines directly.

Task-1974609