Split files and move them according to the new API guidelines. Containing

 - mrp splitted into its main models and files
 - stock code moved into its own models and files
 - various renaming

General remarks concerning cleaning commits preparing the stock migration
=========================================================================

Small update / cleaning before moving and migrating. This commit contains
the cleaning of stock_picking_type and stock_picking models.

The first cleaning performed is to clean methods having a browse record or
a list of records replacing ids parameter. Those are converted into classic
old API methods using cr, uid, ids. This eases the migration as they are
then migrated into multi methods.

Another cleaning concerns naming things. Some methods are renamed to ease
the code readability. Some parameters are also renamed as well as some
variables. This kind of change is performed only when the readability
is improved. Otherwise the code is kept as it is to avoid rewriting too
much of the code.

Finally unnecessary stuff is also removed. This concerns dead code (methods
not used in community nor in enterprise) and unnecessary code splitting
(tools methods called once without real added value are directly put into
their called method).

- stock.move: no specific changes; note that a method called only in mrp
  has been moved to mrp.
- product: no specific changes
- config settings: no specific changes
- wizards: no specific changes

stock.quant main changes
========================

 - ``apply_removal_strategy`` method updated to return only the removal
   strategy instead of having a mix of several things (overrides updated)
 - ``quants_get_**`` methods renamed to ease code understanding
 - quants_unreserve from stock.quant to stock.move model because its primary
   record is a move, not quants

stock.inventory and stock.inventory.line main changes
=====================================================

 - stock.inventory: ``move_ids_exist`` field remove. Unused.

stock.picking and stock.picking.type main changes
=================================================

 - stock.picking: ``move_lines_related`` is removed. Indeed it is used only
   to display a slightly different view of moves contained inside a picking.
   However this field causes a lot of issues when migrated into the new API.
   The view is updated to keep the same look and feel while avoiding an
   unnecessary field.
 - stock.picking.type: complete_name field is removed. Using display_name is
   sufficient for the existing use cases.

stock.warehouse and stock.orderpoint main changes
=================================================

 - stock.warehouse: removed ``resupply_from_wh``, unused field

stock.pack.operation main changes
=================================

 - stock.pack.operation: ``processed_boolean`` fields renamed to ``is_done``
   to match its use in the code.

stock.location main changes
===========================

Note that in this commit a strange override in create has been replaced by a
cleaner override in default_get in order to have something more understandable

procurement main changes
========================

 - in this commit some code located in procurement has been moved to the
   orderpoint model. Indeed those methods take an orderpoint as main
   argument, making it more orderpoint methods than procurement methods
 - ``_prepare_orderpoint_procurement`` method has been merged with its
   strange override in stock_calendar to have something a bit more modular

Major changes:
- No use of UoS anymore

Reason: complete rewrite of the Sale module.

Responsible: fp, dbo, nim

- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
  automatically in all countries thanks to Berne Convention + WTO rules,
  and a reference to the applicable license is clear enough.

Manufacturing Orders can be created from procurements,
as SUPERUSER_ID, since the procurements can be processed
through the WH scheduler, which is always ran as SUPERUSER_ID

In such a case, the record rules are ignored, and a BOM
normally not accessible to a user thanks to the multi-company
record rule could be chosen as the BOM of the MO.

This revision forces to find a BOM from a specific company
in such a case.

opw-640120

The name of the manufacture order created must include the sequence linked
to the company of the salesperson.

opw:632600