[FIX] performance issue with module loading in new API

Old API made a difference between falsy values at the storage level ('' would
be stored as '' and False as False), but client itself would not, and new API
changes behavior to take after client and unify handling. This means a write
of `''` in the old API would be read as `''`, but in the one it'll be read as
``False`` breaking code relying on such a behavior for eq. Such as the
update_list code checking if a module's manifest has been updated since the
last load-to-db.

Fix by special-casing situations where both old and new values are falsy.
[IMP] comment out IdType assertions in BaseModel.browse

These turn out to have significant overhead, especially on e.g. new API-based
search-heavy code, the gencomp is a multiplier and may lead to million+ calls
to isinstance with a class tuple, contributing significantly to the runtime of
the system.

Commenting that lowers the performance worsening of the new API when
installing account to ~5%.

If we want to re-enable it for security purposes, "internal browsing"
(e.g. from search) should use the assertionless _browse instead.
[IMP] minor style improvements
[IMP] should have no effect on performances, but there's no cause to iterate twice on field_dump
[IMP] micro-optimization: dict.pop -> key in dict + del dict[key]

Note: all measurements are from my machine, but the relative gain should be
valid for any CPython (hopefully)

* if the key is in the dict, ``dict.pop(key, default)`` and
  ``if key in dict: del dict[key]`` have about the same runtime.
* otoh if the key is *not* in the dict, the latter is ~3 times faster (0.06
  usec to 0.183 usec on my machine).

Because invalidate is a tight loop where 99% of the iterations of the fields
are *not* in the cache during module installation (for account, I get 19
million checks and 126000 removals), moving from pop to if+del yields a 10%
runtime gain, from 75s to 67s.

An even better optimization would be some sort of algorithmic method to avoid
the 20m iteration/test/test: although they only take 1 usec each, they add up
to a significant runtime.
[FIX] slow-ish running Field.modified

During loading of XML data files for installation of ``account``, the
`field.store` branch is only taken in ~1% of calls to ``modified`` (1547 hits
out of 148000 calls). Creating environments is fairly expensive[0], so
executing it at *every* call to ``modified`` increases the average method
runtime cost by 4x[1].

[0] >40x basic operations like an assignment or iteration loops, though it is
    a noop compared to the search next to it
[1] 4s to 18s on my machine
[FIX] improve average runtime of BaseModel.modified

During loading of XML data files during the installation of ``account``, it
turns out the *vast* majority of non-stored function fields are not cached,
and asking for their invalidation leads to a huge runtime hit for "nothing"
(spinning wheels in ``Environment.invalidate`` but ultimately not doing
anything since the fields aren't cached).

Checking whether the fields should be invalidated before adding them to the
specs list (by collecting all currently cached fields in a set and only
selecting fields for invalidation if they are in the set) leads to ~6x less
hits within invalidate, and lowers the average runtime of BaseModel.modified
from 49s to 18s on my machine.
Merge pull request #15 from odoo-dev/apiculture-perf-xmo

Performance improvements to apiculture