Generic module to compute the stock quantity available to promise

[clonedagain]

Commit 1: Main module + option to exclude incoming deliveries

The "quantity available to promise" is the quantity of a product that you can commit to deliver to a customer.
Depending on the business, it may depend on expected deliveries, manufacturing, expected sales, or many other parameters.
To handle this concept in a modular and configurable way, @lbellier and I add a generic module to compute the stock quantity available to promise, and a 3 pluggable implementations that users can choose from. All implementations can be used at the same time.

Code trick: function field modularity

By default function fields are not very modular (you need to redefine the whole field to override the method). stock_available takes care of this by making the function fields call the pool instead, so that stock_available_immediately and other future implementations need only override the function _product_available.

Changes to stock_available_immediately

The existing module stock_available_immediately by @guewen and @sebastienbeau is turned into the first optional implementation.
stock_available_immediately is rewritten to compute "virtual - incoming" instead of "real - outgoing", which should be mostly the same except for rounding.
The field name "immediately_usable_qty" is unchanged for compatibility, but the field is now called "Available to promise" in the views and help texts (this wording seems more widespread).

Commit 2: option to include products that can be readily manufactured

The module stock_available_mrp takes immediate manufacturing capability into account in the stock quantity available to promise.
We consider a product can be readily manufactured if all its direct components are available.

Commit 3: option to exclude products already proposed in sale quotations

The module stock_available_sale takes sale quotations into account in the stock quantity available to promise, so that sales persons don't include the same products in 2 quotations.

[clonedagain]

There is a small problem with the "context trick", some fields are not computed. I'll fix it and rebase the branch but please keep reviewing in the meantime.

[clonedagain]

Fixed the context trick. It does have a small side effect (adds values to the caller's field_names) that I documented, and I think it's safe.

[guewen]

Wow, impressive. I will try to take some time soon for a review.
Meantime, can you rebase from the 7.0 branch so Travis will check your PR please?

[coveralls]

Coverage increased (+2.76%) when pulling 20cf709 on numerigraphe:7.0-add-stock-available into 316d391 on OCA:7.0.

[clonedagain]

The tests pass, so it's ready for you to review.
Rebased and re-flake8'ed.
I also fixed a small bug (the sale module was not considering the production capability).

[coveralls]

Coverage increased (+2.8%) when pulling c5439f1 on numerigraphe:7.0-add-stock-available into 316d391 on OCA:7.0.

[clonedagain]

There was a small bug that became visible because of last fix (used to product wrong warning messages, now triggered an endless recursion).
It's fixed now and rebased.

[gurneyalex]

@clonedagain what is your opinion regarding this PR and #2559: is it blocking? Something we can fix in OCB if official is buggy?

[clonedagain]

Fixing this in OCB would not be fair to users who stick to the official branch. Our users were pretty unhappy when the onchange broke, and it was rather hard to track down.

[gurneyalex]

OK, thanks (and apologies for the long delay on considering this PR...).

I've set things as work in progress, and asked for an update on the official addon issue.

[clonedagain]

Rebased to avoid conflicts due to recent flake8ification.

[coveralls]

Coverage decreased (-3.02%) when pulling 19182aa on numerigraphe:7.0-add-stock-available into 23f8a9b on OCA:7.0.

[clonedagain]

I've split this PR in 2, so now the blocking part is isolated in #25.
Travis build passed (the errors in the log seem unrelated): can you please tag "needs review"?