[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] export: in saas-3, req becomes request.

Error during forward port b9275da8a52255d0fc3f914de9d406612e7dde50
[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] 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