Steps to reproduce:
- Download payroll and Time off
- Time Off > Configuration > Time off types
- In Paid and unpaid type, set 'Take Time Off in' to Hours

- Employees > Pick one > Time off
- Click calendar day and create 2 leaves:
-- Paid type, Custom hours from 8:00 to 9:00
-- Unpaid type, Custom hours from 9:00 o 10:00
- Time off > Management > Time off
- Approve and validate both leaves

- The employee needs to have a running contract so if needed
-- Payroll > Contracts > Contracts > New
- Payroll > Regenerate work entries for your employee
- Leaves are generated as a single block of type 'Generic time off'

The leaves are merged. The Interval class sorts its entries' boundaries in
such a way that it will see the start of an entry before the stop of the
previous one if the start/stop time are the same. Its counterpart
WorkIntervals does not merge overlapping entries.

i.e with entries 8:00-9:00 and 9:00-10:00 Intervals will interpret as:
8:00 start, 9:00 start, 9:00 stop, 10:00 stop => Merged entries.
And WorkIntervals as:
8:00 start, 9:00 stop, 9:00 start, 10:00 stop => No merged entries.

This happens regardless of the content of the merged resources, in this
case two different types of leaves which should not be treated the same
by nature (Paid/Unpaid).

When going though the leaves, we currently loop over the associated work
intervals, this is part of the reason several leaves are processed as a
single interval. The only reason we need the attendance interval is
because some work entry types can take precedence over leaves (For
instance a long term medical disability must supercede a public
holiday).

In the interest of avoiding a change in the return type of the method
'_get_interval_leave_work_entry_type' we instead rebuild the intervals
with the bounds of the leave and the work entry type of the attendance.

opw-4193334

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182273

# Global context:
TSB, LZZ, THBE and me (BIB) had a very long meeting to find out what
would be the better the solution to allow a UK company to use the
OSS tax system with Belgium as its entry point.

The UK company has a wharehouse in Belgium and thus needs to report
anything coming out of that wharehouse to the on the Belgian VAT report
and the "Belgian" OSS tax report.
It also needs to invoice any Belgian with the Belgian taxes and VAT (and
thus can't use OSS for that one).
Some of their product might be purely Belgian and thus only have a
Belgian tax set on them. We thus need to support both the mapping from
the motherland UK and from Belgium.

The following are required:
- Creating the Belgian VAT taxes.
- Creating the OSS taxes as they would be for a Belgian company.
- Create the fiscal position mapping from Belgian tax to EU taxes.
- Create the fiscal position mapping from UK to EU taxes.

The main goal of the task is to:
- be able to instantiate OSS on a specific branch: we go from the
  current one up and we instantiate OSS to the first one with a TAX ID.
- we should be able to use the classic OSS tag as usually.
- be able to report those numbers in the OSS tax report.

## [IMP] l10n_eu_oss: OSS on first branch with a TAX ID
The aim of this commit is to allow to instanciate OSS on the first
branch having a tax id instead of always instanciating OSS on the root
company.

### Context:
The end goal is to allow to instanciate OSS for a company outside EU and
let it use sub branch to manage the tax mapping.

### Previous to this commit:
OSS taxes gets installed automatically on all companies when loading a
chart template or installing the OSS modules.
OSS taxes and fiscal position are always setup on the root company.

### After this commit:
OSS taxes never gets installed automatically when loading a chart template
or installing the OSS module.
OSS taxes and fiscal position are setup on the first sub branch having a
TAX ID.

task: no task

## [IMP] l10n_eu_oss: OSS on EU branch

### The aim of this commit is to:
allow non EU countries to have an EU branch
with an EU VAT number that can have both the taxes for that specific
country and the OSS taxes mapped from that country to the other EU
countries.

For that branch to be able to see the OSS tax report, we have to be able
to set the fiscal_country_id as an EU one.

It also needs to be able to instantiate the EU tax from that country.
To allow that, we need a foreign VAT fiscal position. In order to do
that, we had to remove the constraint that prevent to have both a
foreign vat fpos and the fiscal_country_id to be set on the same
country and same vat number.

task: None

## [IMP] l10n_eu_oss: allow to map allow available taxes + add UK tax ma… …pping

### The aim of this commit is to:
- add the mapping from UK to other EU taxes for OSS.
- make the mapping between all available tax that wouldn't have been
  created by the OSS feature

### Previous to this commit:
- UK taxes couldn't be mapped automatically
- taxes from the parent companies aren't mapped automatically

### After this commit:
- UK taxes are mapped automatically
- taxes from the parent companies are mapped automatically

task: None

## [FIX] l10n_eu_oss: avoid between oss taxes together
The aim of this commit is to avoid oss taxes to be mapped one to
another.

### Context:
During the refactoring of the chart_template in
5125748 , changing the module name for
the search was forgotten.

### Previous to this commit:
When you refresh the taxes several time, some oss taxes will be mapped
to some other in some fiscal position.

### After this commit:
OSS taxes mapped together shouldn't happen anymore.

Enterprise PR: https://github.com/odoo/enterprise/pull/71006
task: no-task

Forward-Port-Of: odoo/odoo#181954