[FIX] Make sure we can select dropship on purchase order and see the related customer and invoicing based on shipments works for sale only

[FIX] Sale should lead to invoicing
[IMP] Journal should not depend on picking type code when in dropship

Make sure drop shipment with invoicing on sale orders only, works.
Also the picking type of dropshipping should be incoming.  This
makes it possible to select it on the purchase order.  This also fixes #3421.
And we can create a dropship from a purchase only. (not the good way)
For this, we make the invoicing based on the shipment look at the
purchase related and not on its picking type code as the picking type
of dropshipping is changed back to incoming.
The purchase order will also show the customer address when in
a dropship case.

Closes #3421
[FIX] Warehouse should be False on PoS and dropship picking types
[IMP] Put default_invoice_state in context of move_lines of picking.
[IMP] point_of_sale: access taxes via id for performance reasons

[IMP] point_of_sale: do not recompute taxes_by_id every time
[IMP] point_of_sale: add support for taxes included in base amount.
Update CONTRIBUTING.md
[FIX] report add the humanreadable option to barcode image generator

Closes #4334
[FIX] product: variants prices (extra price) digits precision

When adding an extra price for a variant (through the button variant prices in the product template form) with a digits precision greater than 2 (4 for instance), the computed public price did not keep the digits precision of the extra price
[FIX] payment_buckaroo: brq_test expects boolean
[FIX] website_sale: compute base price from default company currency to user currency to display the good lst_price or price extra
[IMP] enable loading custom models/fields and views from module data files

Loading views for custom models from module data files was not possible because
custom models and fields were introduced into the registry after all modules
were loaded.  As a consequence, the view architecture did not pass the checks.

This patch takes a different approach: custom models and fields are loaded
early on in the registry, so that views can be validated.  The trick is to take
special care of relational custom fields: we skip them if their comodel does
not appear in the registry.  This allows to install and upgrade modules that
create/modify custom models, fields and views for them.
[IMP] registry loading: setup models only if necessary

When loading the registry without any module installation/upgrade, models are
set up once instead of twice.  In other cases, models are always set up before
installations/upgrades.
[FIX] web: reordering in editable list views

Broaden the set of conditions where reordering is allowed. Lists can be
reordered when they are sorted by sequence (or sequence ASC)

opw-619465
[FIX] hr_holidays: Add missing context check

Fixes #4341
[FIX] odoo.py fix fetching of git remotes

remove the useless heads in local refs so that:

git checkout -b master odoo/master

and

git checkout -b master-name odoo-dev/master-name

works.
[FIX] website_sale perfomance on public categories

Use a domain instead of python filtering when loading root categories.

Closes #4324
[FIX] payment_buckaroo: copy values dict to avoid altering original dict

_buckaroo_generate_digital_sign uses the values dict to generate the shasign
At some point, it alters the dict, it removes BRQ_SIGNATURE, but, as the values dict was not copied, it altered the original dict.
So, the key BRQ_SIGNATURE was not anymore present for methods called after _buckaroo_generate_digital_sign.
For instance, the overriden method form_feedback of website_sale payment