Linked PR in upgrade:
https://github.com/odoo/upgrade/pull/3886

#### Summary
Add fields to the product representing the type and amount of
supplementary units the product represents for intrastat purposes,
replacing the old system of trying to calculate this from the units of
measure on the move lines.

#### Context
In intrastat, supplementary units are a way of describing the quantity
of goods in a way that is more relevant than the default (kilograms) in
the statistical context in which the data is utilised.

For instance, when measuring the passage of commodity:

code: 93012000
description: "Rocket launchers; flame-throwers; grenade launchers;
torpedo tubes and similar projectors"

the supplementary unit is "p/st", meaning unit (rather than kilograms).
Which is to say, that when you're selling rocket launchers;
flame-throwers, grenade launchers, etc to other European countries, the
EU it's more statistically relevant to discuss the number of units sold
than the weight. This is true of a large number of other commodities
which can be measured in other ways (e.g. 100 p/st: by the hundreds of
units, c/k: metric carat, 1000 kWh: thousand kilowatt hours, etc)

#### The Problem
Previously, the problem was that the information regarding the
supplementary units was not included in the report. Since it became a
legal requirement, a solution was created (in stable) that utilised
odoo's units of measure to cover a number of the most common
supplementary units: https://github.com/odoo-dev/enterprise/commit/2fbe4deb2051ca8e8559c8b68c66b0c245668480. However, this is inadequate for a
couple of reasons:
a) It provides little control to the user, who might wish to use units
of measure that are not the same as the supplementary units.
(e.g. Sell flamethrowers by the kilogram, though the supplementary unit
is per 'unit').
b) It doesn't cover the supplementary units for which there isn't a
corresponding category in odoo by default.
(e.g. Sell uncut diamonds, with corresponding supplementary unit:
c/k (metric carat), for which there is no corresponding unit of measure
in odoo).

#### The Solution
The first part of the solution involves adding a field to the
account.intrastat.code model. The field is a selection field called
'supplementary_unit' and represents the supplementary unit for the
commodity code. This also allows us to remove the enormous dictionary
currently representing the relationship between commodity codes and
supplementary units in
account_intrastat/models/supplementary_units_codes.py.

The second part of the solution is to have a field representing the
ratio of the product quantity to the number of supplementary units. This
field is called intrastat_supplementary_unit_amount on the product.product
model. If the currently selected commodity code field has a
supplementary unit associated with it, then the
intrastat_supplementary_unit_amount field is displayed below the
commodity code field. If no supplementary unit is associated with the
commodity code, then the weight field is displayed instead. This is the
case for both the product.product, though the product.template makes use
of a related field that displays the value of the
intrastat_supplementary_unit_amount on the product variant (if the
product variant is a singleton), and is otherwise invisible.

The intrastat_variant_id (commodity code) field has been renamed on the
product.product to intrastat_code_id. The intrastat_id (commodity code)
field is removed from the product category and the product.category
views are removed.

The product template and product variant views are adapted to include
these fields. Additionally, the product template view is adapted to hide
the intrastat fields (including those that weren't introduced in this
commit, i.e. commodity code and origin country) when there is more than
one product variant, similar to the way weight and volume is displayed.

The report is altered so that the SQL query now fetches the
supplementary unit field and performs the logic necessary to calculate
the supplementary unit column.

The quantity is calculated with reference to the reference unit of
measure, and then used to multiply the supplementary unit amount. This
avoids the problem where, for instance, a dozen is used as a unit of
measure, and the quantity is 1. Then the
intrastat_supplementary_unit_amount should be multiplied by 12 rather
than 1.

The _intrastat_fill_supplementary_unit function and references to it are
removed as the logic it performs has been superseded.

The existing tests have been minimally reconfigured to work with the
changes. This simply required adding the values of the
'intrastat_variant_supplementary_unit_amount' field on the
product.product records used in the tests.

task-id: 2884512