Master i18n fp

Improvements
-------------------

This branch improves the translation mechanism, mostly needed for frontend:

1/ Translation of XML/HTML fields: are managed like arch in ir.ui.view. Splited in smaller goups rather than having to translate the whole field (e.g. a blog, a product description, etc.)

2/ Typos management when translating from the website: if a typo is fixed on an english string, you do not have to translate the whole blog again in all languages. If you completely change a paragraph, it has to be translated again (only the paragraph, not the whole blog). If you just fix a typo, the translated versions remain.

3/ The translation of views is not a specific use case, it's now translate=True on the arch fields on ir.ui.view.

More efficient, less lines of code.

Changes
------------

* Fields support not only translate=True, but also translate=CHUNK_METHOD. This method takes a string in argument and return a list of strings to translate.
* From the client side point of view, translate=CHUNK_METHOD is like translate=False. (e.g. you can not modify the french version of the arch field of views)
* The context on translations changed in the exported .PO.   #: view:resource.calendar.leaves:0 is now  #: model:ir.ui.view,arch:resource.view_resource_calendar_leaves_search

Done
-------

- tested to import .PO
- tested to export .PO
- tested in the frontend

Todo
-------

- More tests
- put chunk_xml (in ir_ui_view) in tools/xml.py and use it in blogs, product description, ...
- improve chunk_xml to not split around \<b\>, \<i\> and \<strong\>, \<span\>, \<em\>
- Adapt the frontend to support translation of HTML fields like views
- Re-export .POs in all languages (ask ODO for this, he has his own script to do this)



The replace() call seems super brittle, there will be cases where term A is contained in term B, so after the pure-text replace of A, B will not be translated. Perhaps xml_chunk_translate() could work in translation mode *and* in export mode or something, making it more symmetric and reliable?

There might also be a way to batch the retrieval of the translations, or to cache them per-view in a way that is more efficient than the basic ir.translation cache. That's probably a final optimization step though.