[IMP] add read access to all users for product.pricelist.type

In new API, selection field value is checked (against the selection's possible
values) at both read and write. For pricelist.type this requires read access
to product.pricelist.type.
[ADD] demonstrate broken handling of rules access denial in new API
[FIX] only prefetch other cached records with read field uncached during _read_from_database

If expansion of the recordset is done during _prefetch_field, if one of the
prefetches (not the base record(s) but one of those selected by
BaseModel._in_cache_without) can't be read by the current user (due to an
access rule or for field reading reasons, or whatever) the whole read is
failed, even if the record which was specifically asked for could be read on
its own.

By only expanding the read set in _read_from_database, the cache is correctly
set but read() and _prefetch_field() only check the records explicitly asked
for for AccessDenied, prefetched records will only be asked if they are ever
accessed.

fixes #1013
[FIX] filtering out of records which shouldn't be fetched/prefetched

A todo would only filter out records selectioned by the same field's caching,
it should filter out on the whole prefetching selection or an other field
could/would just add it back to the set of records to fetch (and lead to Bad
Things).

Note: this probably deserves a test somehow, but I'm not quite sure how the
todos thing works so...
[REM] cache setting in _prefetch_field
[FIX] calendar: invalidate cache to avoid (pre)fetching invalid virtual IDs

Because the new API basically browses everything, the virtual IDs used by
calendar.event are added to the cache and prefetching tries to get them from
the database resulting in conversion errors. These ids have to be forcibly
evicted to avoid the error.
[FIX] expected browse_record can be an integer

If no filter is specified, the geoip library is installed and the user's
address can be geolocated, ``country`` is assigned an integer (the id of the
matching country) whereas the filtering code expects a browse.

fixes #1148
[FIX] website_hr_recruitment: various warnings
[REM] asynchronous database creation method

It's broken (though easy to fix) and not very useful, if third parties want to
create databases asynchronously they can handle the asynchronicity on the
client-side (an HTTP request is easy to make asynchronously after all) and
call the synchronous `create_database()`.

fixes #1137, after a fashion
[IMP] website_hr_recruitment: new API
Merge pull request #1076 from xmo-odoo/8.0-shop-fix-xmo

Fix access rights issues in new API for the shop home page
Merge pull request #1166 from xmo-odoo/8.0-jobs-list-geo-xmo

8.0 jobs list geo xmo
Merge pull request #1169 from xmo-odoo/8.0-remove-async-db-create-xmo

Remove asynchronous XML-RPC database creation function
[FIX] ensure Field strings are decoded before comparing them to one another

fixes #773
base_gengo: [FIX] change http status code for gengo_callback because status 100 make response very slow
[FIX] Cron for gengo was always in mode 'do missed' what we don't want, replace 0 by False
[FIX] Remove unused regexp to find view_id from js which was breaking the count words
[FIX] "prefetching" removing even the records specifically asked for

16d6744 turns out to not be great, because it filters out the todos for
prefetched fields (rather than those just for the field being asked) there are
situations where it ends up not fetching the records it was originally asked
for and breaks a bunch of stuff e.g. unreconcile line in bank statements

Force the ids explicitly asked for back in the fetched set, so that the
prefetch is at most a noop, rco will have to take an actual look at it.
[FIX] models: display_name and name_get mismatch

- display_name useses of name_get and not the other way around:
The name_get should not call _compute_display_name, _compute_display_name should call namge_get. The previous behaviour was not backward-compatible with the old api. All the models redefining name_get (still

- Do not set an inverse function to display_name:
In most cases, writing on display_name writes on _rec_name (if any, not mandatory). If the display_name computation is redefined, we need to redefine as well the inverse method to avoid unexpected behaviour
This required to also modify tests in base_import as readonly fields are avoided.

- Remove search method on display_name:
For the same reason as for the first point, it could be good that searching on display_name use name_search (and not the other way around). However doing this would be very unefficiant (need to do the search, without limit, extract the ids of the name_get result just to generate a subdomain ('id', 'in', [...]). As in most cases it would anyway mean to search on the _rec_name it's better to directly do so.

- Changing label to avoid mismatch:
In view displaying the list of fields or when a match is made on the label of a field (e.g. when importing csv file, matching is made on both label and technical name), the fact that display_name field has '
Calling it 'Display Name' will avoid most errors.

- remove display_name definition from website_forum_doc,ir_model:
These fields are doing the same thing as the display_name of the new api, we can remove them. We need to keep the one for res.partner as it's a stored field.