[FIX] tools.translate: when loading entries from a PO file, use also the POT.

On Launchpad, as commented on bug 933496, PO entries (and their comments) are
shared between series. This mean that e.g. the 7.0 series can have the wrong
`reference` comments (those beginning with #:) as they would be copied from say
the trunk series. Those `reference` comments are used to import translations
and look them up.

This patch adds a few lines of code to tools.translate so that targets
defined in the POT `reference` comments are used in addition to those from the
PO file.

Also adds a test module to validate the new behavior.

This patch stems from:
 - the 6.1 branch by Vo Minh Thu:
    https://code.launchpad.net/+branch/~openerp-dev/openobject-server/6.1-fix-po-targets-933496-vmt
 - the 7.0 port by Numerigraphe:
    https://code.launchpad.net/~numerigraphe-team/openobject-server/7.0-fix-po-targets-933496-vmt
[FIX] tools.translate: addons path resolution failed with duplicates

When the addons_path config contained the
default path, the system was working with
an empty addons_path in the middle of the
other paths. This empty one matched for all
files, making all files appear to belong to
the root path component, e.g. `home` if the
root path is in /home.
Refactored a bit to avoid duplicates and
redundant path calculations.
[I18N] Update all 7.0 translation templates with latest terms and annotations

Total new terms: 168
Total deleted terms: 95
Total identical terms: 16329
(Some modules skipped, typically all l10n_* modules)
[I18N] Update 7.0 translations with latest changes on Launchpad

See also https://github.com/odoo/odoo/wiki/GitHub-Transition#translations
[MERGE] Forward-port of 7.0 up to 85d2b45
[FIX] mail, mass_mailing: do not add a link to access the document
when the email is not a notification, or not an email usign the automatic
threading. This means that when doing mass mailing with a fixed reply_to
there won't be any link to access the original document, which is what
we want. Otherwise when mailing partners, they have a link to access
their own partner profile, which does not make sense.
[FIX] export: in saas-3, req becomes request.

Error during forward port b9275da8a52255d0fc3f914de9d406612e7dde50
[FIX] web: CharDomain form widget: fixed change selection
button not correctly displayed depending on the effective_readonly
parameter. It is now correctly computed.

Also added a link to see records when in view mode, instead of not
being able to see the selection if not in edit mode.
[MERGE] Forward-port saas-3 up to 9b55532
[MERGE] Forward-port saas-4 up to 9a84d55
[MERGE] Forward-port saas-5 up to acbdac4
[FIX] google_{account|calendar}: fix synchro

- no more tracebacks when trying to sync more than once with Google Calendar
- no more context hacks, explicit return of `ask_time`.

(Closes #1588)
[FIX] base : context evaluation with active_id server side. It now keeps the active_id in case of a refresh.
[FIX] test_new_api: missing parent menu
[I18N] Update 8.0 translation with latest source code
[FIX] models: onchange on new records do not nullify fields from _inherits records
[FIX] models: stored func fields computation on one2many write

On one2many fields writing in an existing record (not when creating new record), the computed stored fields of the one2many were not re-computed correctly
Computed stored fields were marked as modified only if no_store_function was not set to True in the context. no_store_function is set when writing one2many records on an existing record.
Now, these computed stored fields are marked as to be recomputed, but are recomputed later, at the end of the existing record write
[FIX] models: `_convert_to_write()` shall not return `NewId`

The result of _convert_to_write() is intended to be pass directly to
`write()` or returned to the client (`onchange()` and `default_get()`.
`NewId` is as special value that must not be stored into the database
or exposed to the client.
[FIX] point_of_sale: the product name field changed to display_name to include variants information, this should be reflected in searches as well.
[FIX] point_of_sale: the order uid were generated via timestamp, which were not sequencial or easy to understand, they are now generated with the order id and order sequence number which are sequencial