This commit fixes a symptom of a more general problem which will be
investigated later.

Steps to reproduce:
- Go to apps
- Install website
- Follow the configurator flow up to entering edit mode
- Go to the 3rd tab of the editor panel
- Change the "background" color of the third color combination and
  choose one of the gray colors
- Go to the backend => SCSS compilation crash

Basically, "frontend" color (complex) maps are available in all assets
(via the variables parts that all assets have in common). The original
plan was for them to be used in shared "frontend" environment like the
mass_mailing application. The web_editor SCSS generation uses those
variables to customize bootstrap variables... but it conflicts with the
backend also customizing those. That's why there is code to "clean" what
the web_editor app does when you are in the backend environment. The
problem after the mentioned steps is that this "cleaning" is done too
soon: gray colors are removed from maps to not alter backend grays and
a web_editor css rules wants to access those gray values if configured
to be used liked mentioned in the steps to reproduce. This commit
basically reviews what was done at [1].

In master it should be reviewed so that the web_editor probably does not
touch any bootstrap variable when in a backend environment and/or some
code should simply be moved to the website app only. See also
web_editor.common.scss where many CSS rules depends on this and are
available in the backend... while they probably should not (like the one
which tried to use that gray value like explained above). But in stable,
we wanted to avoid changing too many things.

However, this was only a symptom of the problem: the fact that some
CSS rules should not be loaded in the backend is not a critical issue.
The real problem is that those CSS rules were breaking because the
backend assets are actually generated using website-specific assets
while the backend is supposed to be website-independant. That's probably
a bug introduced with the new assets system (ir.asset) which would
explain why this bug cannot be reproduced in 14.0. This will be looked
into in a future update. Also, this could be backported later if judged
necessary or if a traceback is actually found.

[1]: https://github.com/odoo/odoo/commit/70f35620babdfdf43e2c603efbf37f2cf7399240

opw-2735123

Forward-Port-Of: odoo/odoo#88922

## goal:
The aim of this commit is to allow amls with other tags than OSS to appear
in the tax report.

## Context:
Previously, the oss tax report was supposed to be independent from the
national tax report but the feature evolved and it is now required.
The tags on the amls have to be considered by the tax report but the tax
closing entry shouldn't consider those.

## Before this commit:
- amls wearing the OSS tag amongst other tag weren't taken into account to
compute the tax report line of other tag.
- amls wearing the OSS tag weren't taken into account to compute the
tax closing entry.

## After this commit:
- amls are taken into account to compute the tax report even if they wear
the oss tag.
- amls wearing the OSS tag aren't taken into account to compute the tax
closing entry.

bugfix ticket: #2796340
support ticket: #2768622, 2768634

enterprise-pr: https://github.com/odoo/enterprise/pull/25591

Forward-Port-Of: odoo/enterprise#26301
Forward-Port-Of: odoo/enterprise#25591