[FIX] web: ensure one2many field destruction on button cancel

The destruction of one2many fields is forced with the event change:effective_readonly
This revision add the forced destruction for cancel(discard) button as well

Otherwise, one2many fields are not properly destroyed when hitting the button "discard" (from save or discard).
This can be problematic for one2many editable list views (such as invoice lines) if you discard while having a mandatory field not filled in the invoice line: You can't recreate an invoice, the one2many editable list is messed up

Use case: Create an invoice, create a line, leave the description, required field, empty. Then, discard. Then, click on create.

opw-616946
[IMP] Cancelling of procurements related to purchase orders should check state/UoM of the purchase order line + optim action_cancel

[IMP] Add tests

[IMP] Clean up
Merge branch '8.0-wmspurchaseproccanceloptim-jco' of github.com:odoo-dev/odoo; branch '8.0' of github.com:odoo/odoo into 8.0
[IMP] Cancelling of procurements related to purchase orders should check state/UoM of the purchase order line + optim action_cancel

[IMP] Add tests

[IMP] Clean up
Merge branch '8.0' of github.com:odoo/odoo into 8.0
[IMP] No lot in qty update as it is only confusing #3984
[MERGE] purchase: speed up cancelling procurements, add test, hide lot in quick inventory update

Manual re-merge of following commits, to fix mainline history:
  3ea978bc115f1121f841be6ec5d50b224579b497
  f76d714fb9940c258955d207d1601732fd23d7d3
  c12f4efc539e2be6e1b1c5338a4240419e500177
[FIX] (portal_)project_issue: remove duplicated field

Field priority in kanban view was present twice which made inheritance harder
[ADD] Packaging: also publish source dist .zip file
[ADD] Packaging: Debian and CentOS Dockerfiles for nightly builds tests

This way we'll be using docker cache to spare dependencies download time.
[FIX] website_blog: fi xbanner in demo data
[FIX] web: user lang has the priority on partner lang

Potentialy, the timezone too.

On item action click (such as menus in More.. and Print..), the data in form view had the priority on user context (through the sidebar_eval_context)

Therefore, if a field "lang" was present in the form view (like in partner form), the web/action/load xmlrpc call was using the partner language instead of the user language.

Example of wrong use case before the fix:
 - Set the user language in French, then go to a partner form of a partner with English set as language
  - Click on any button of the partner form, such as the "Invoices" button, notice that the last item of the breadcrumb is in English, instead of Frenh (the user language)
  - Click on any menu opening a wizard in the More.. dropdown menu, notice that the wizard title is in English instead of French
  - Print any report from the Print dropdown menu, notice that the report file name is in English. If you print the same report for the same partner but from the list view, the report file name is in French.
[FIX] stock: when putting product in pack from barcode interface, should return package_id instead of True
[FIX] web: scroll handling for many2one selection

If the many2one selection height was too big (bigger than the browser page), it wasn't possible to see all options, because the body is set as overflow: hidden;

Moreover, if you opened a many2one selection and then scrolled the page, the selection moved with the scrolling, while it should be sticked to its input field
[FIX] email_template: default model for save as new template feature

When sending a message with the "Compose new message" button on the right of the user menu, in the top bar, if you tried to save the message as template, you had a traceback because model field of email.template is mandatory, but was set to True because there is no model in such a case.

As there is no any relevant model in such a place, and that the field is mandatory, mail.message is pretty convenient as the default value.
[IMP] models.py: increase logging level for columns that can't be casted automatically when upgrading a module.
[FIX] account_analytic_analysis: default pricelist for contract sales order

With 'Fixed Price' enabled, a button giving the possibility to list all sale orders appears.
When browsing the list, there the possibility to create a new sale order.
The contract pricelist should be used by default when coming from this specific button.
[FIX] google_calendar: recurrent event syncrhonization

When an attendee is added exceptionnally in an instance of a recurrent event, do not try to sync the basic recurrent event in his calendar
[FIX] google_calendar: deleted excluded recurring event

Do not try to delete an excluded recurrent event added in Google, but not yet syncrhonised in Odoo (immediately deleted for instance)
[FIX] product: pricelist: multiple corrections in UoM-related conversions

Pricelist computations need to consider 2 different Units
of Measure:
 - The default product UoM (product.uom_id), used as reference
   for the various quantities and amounts specified in each
   pricelist rules.
 - The `context UoM` is the UoM in which the result is requested,
   that is the list price UoM.

For example the 'price_min_margin' amount is meant for the unit
price of 1 x default UoM. When the context UoM is not the default
product UoM, it can be any UoM of the same UoM Category, and the
various quantities and amounts specified on the rule need to
be adapted accordingly:
  - min_quantity (expressed in terms of the default UoM)
  - price_surcharge (specified for 1 x default UoM)
  - price_min_margin (specified for 1 x default UoM)
  - price_max_margin (specified for 1 x default UoM)

The UoM corrections were not done consistently and resulted in
wrong prices when computing the price using a non-default UoM.
The cases were a conversion was needed or not were not properly
identified within the _price_rule_get_multi().

After this commit, the various code branches in _price_rule_get_multi
always ensures that:
 - price requested for: `qty` of `qty_uom_id`
 - `qty_in_product_uom` is the requested `qty` converted to default UoM
 - current (intermediary) price: `price` for  `price_uom_id`

Therefore `price` and `price_uom_id` are always in sync, and `price_uom_id`
can always be compared with `qty_uom_id' in order to know whether
a conversion is still needed.

This patch also corrects and extends the regression tests
introduced at revision 79ebe10.