Before this commit, a "translation hash" was calculated and added to the
session_info. The method used to compute the hash needs to compute the
translations, which can be slow, and only the hash is cached. This hash is then
used by the client to fetch the translations twice. Once directly in the page
template, and once in the localization service. This is done to get the
translations as quickly as possible. Normally, the browser cache should prevent
from the second request from being made (since the hash is the same), but this
doesn't always seem to work as expected, as all requests are started as soon as
possible, so if there is a small delay in the first request the second is also
be made. So in the worst case scenario, translations are calculated 3 times by
the server, and the web client waits for them to finish before rendering.

Now, a translation hash is no longer calculated to be placed in session_info,
speeding up session_info and the page. The translation hash is sent to the web client
with the translations themselves.

Only the first time, the web client will waits for the translations to be
rendered. The next time the user accesses the web client, the cached
translations are used. Each time the user accesses the web client, the
translations are fetched. If a cached translation exists, the hash of the
cached translation is used to fetch the translations. The new route computes
the current hash of the translations, compares it with the one it received and
if it's the same simply replies that there has been no change; if the hash is
different, it replies with the computed translations and the new hash.
Note that when the hash is computed, the translations are kept in a cache to
avoid having to compute the translations twice.

opw-4737228

Co-authored-by: Rémy Voet <ryv@odoo.com>