The VIES database is a database of EU VAT numbers that can be accessed
to confirm the validity of an EU VAT number for cross border transactions 
within the EU.

At present the user can select an option in the settings to check VAT
numbers against this database. If the VAT number fails this validation,
the result is a non-blocking banner message that informs the user that
the VIES validation has failed, but has no further ramifications (the
user can still use an unrecognised VAT number).

This non-blocking functionality is still desirable, however we wish to
determine the validity of certain fiscal positions based on whether the
VIES VAT check is valid.

If VAT is required on a fiscal position, there are new conditions for
automatically applying the fiscal position.
1) Is VIES VAT check enabled on the company? If no, then use the normal
behaviour.
2) Is the country of the company within Europe, or is the fiscal
position one on which a Foreign VAT is defined and the country in which
the fiscal position applies is in Europe? If no, then use the normal
behaviour.

3) If the answer to the above two questions is yes, then whether the VAT
is valid (and the fiscal position is automatically applied) is
determined by the the "vies_valid" field on the partner.

The boolean "vies_valid" field is added, and populated based on the
existing onchange function for the banner, triggered when the
VAT/Partner changes. It can be manually edited by the user and changes
to this field are tracked in the chatter. It is added to the partner
view as a checkbox visible next to the VAT. A computed field is a added
such that the "Vies Valid" checkbox is displayed on the partner form
conditionally based on whether company has the vies vat check option
enabled in the settings. The existing VIES check failed banner and
associated field is removed.

A hook called _get_vat_required is placed in the method on fiscal
position that retrieves the appropriate fiscal position for a given
account move, and it is overridden by a function in base_vat, which
specifies whether the partner/delivery address matches the
'vat_required' condition based upon the above listed conditions.

task-id: `3218194`

Note: This pr contains all changes of #116700 regarding assets unique computation except the assets cache. 

The _glob_static_file is already there to ensure a consistent generation as well as preparing the api for the static cache.

During the assets generation/invalidation one of the most expensive task is to
- list all files needed for one assets
- get the timestamp of the file

This is mainly visible when the bundle already exists, but we want to ensure it is up to date.

In prevision of a memory glob, this commit changes the api of multiple call in order to propagate to information from get_path to the AssetBundle, making some optimization, ....

Note that this commit also removes call to `get_module_path` and `get_resource_path` to get a real speedup.

Some values to show speedup linked to all changes:

Assets pregeneration check (enterprise runbot)
Before all changes:
js: ~3s
css: ~1s

After all changes (including static file cache for memory glob):
js: ~0.6s
css: ~0.2s

After this pr (approximated value tested in a different environment):
js: ~1.5s
css: ~0.4s


# Justification of changes:
## split js and css unique
- this will mainly allow to avoid to regenerate css bundle when a js file is modified and vice versa
- this will allow to help to simplify the way the unique is computed, no need to generate WebAssets for all files, we can get
the one of the files of our filetypes in the asset bundle.

## passing debug to the AssetBundle
Before that, the responsibility of passing the debug was given to the `to_node`
This is mainly needed because now the modified time is part of the information given when generating the bundle.
This parameters allows to ignore timestamps given at init if we are in debug=assets. This information is stored on the AssetBundle and there is no need to 

## _process_path extraction from _fill_asset_paths
It looks like the instantiation of the closure had a visible impact, a noticeable speedup was observer after extraction.

## is_wildcard_glob**: 
```python
# long path: /home/xdo/osrc/master/odoo/addons/web_enterprise/static/js.some_file.js
In [33]: timeit.timeit("""WILDCARD_CHARACTERS.isdisjoint(part)""", """WILDCARD_CHARACTERS = {'*', "?", "[", "]"}; part= '/home/xdo/osrc/master/odoo/addons/web_enterprise/static/js.some_file.js'""")
Out[33]: 0.99594196700491
In [34]: timeit.timeit("""any(char in part for char in WILDCARD_CHARACTERS)""", """WILDCARD_CHARACTERS = ['*', "?", "[", "]"]; part= '/home/xdo/osrc/master/odoo/addons/web_enterprise/static/js.some_file.js'""")
Out[34]: 0.4327025180682
In [35]: timeit.timeit("""'*' in part or '[' in part or ']' in part or '?' in part""", """WILDCARD_CHARACTERS = ['*', "?", "[", "]"]; part= '/home/xdo/osrc/master/odoo/addons/web_enterprise/static/js.some_file.js'""")
Out[35]: 0.122356166015379

# short path: web
In [42]: timeit.timeit("""WILDCARD_CHARACTERS.isdisjoint(part)""", """WILDCARD_CHARACTERS = {'*', "?", "[", "]"}; part= 'web'""")
Out[42]: 0.106310188071802
In [40]: timeit.timeit("""any(char in part for char in WILDCARD_CHARACTERS)""", """WILDCARD_CHARACTERS = ['*', "?", "[", "]"]; part= 'web'""")
Out[40]: 0.41943872300907
In [41]: timeit.timeit("""'*' in part or '[' in part or ']' in part or '?' in part""", """WILDCARD_CHARACTERS = ['*', "?", "[", "]"]; part= 'web'""")
Out[41]: 0.08835467300377786
```

## os.path.join vs os.sep.join
```python
In [49]: timeit.timeit("""os.sep.join([addons_path, *path_parts])""", """import os; addons_path='/home/xdo/osrc/master/odoo/addons';path_parts='web_enterprise/static/js.some_file.js'.split('/')""")
Out[49]: 0.19142860104329884

In [50]: timeit.timeit("""os.path.join(addons_path, *path_parts)""", """import os; addons_path='/home/xdo/osrc/master/odoo/addons';path_parts='web_enterprise/static/js.some_file.js'.split('/')""")
Out[50]: 1.2845886170398444
```



# Security:
## Removal of some checks in get_paths
Checking that the normalized path is in a addons_path with addon and static should be enough.
This is actually more strict than before were only the xml file must be in a static file, the check is also more precise.

After that the fullpath is propagated and if not present, this must be an attachment or a non aggregable asset. 
One file was moved from non static directory to static in another pr to make it work here.
After that the fullpath is propagated to _get_asset_paths and  _get_asset_content:

```python
            if full_path is not None:
                files.append({
                    'atype': mimetype,
                    'url': path,
                    'filename': full_path,
                    'content': '',
                    'media': media,
                    'last_modified': last_modified,
                })
 ```
 full_path at this point can be False or have the value coming from get_path
 
 FInally AssetBundle still uses file_open to fetch the content as before.