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)
- check if fields_get() returns translate=False when translate=METHOD on field (I do not remember if I did it or not)



`difflib.get_close_matches()` returns a list of best matches, even with `n=1`. Isn't `[0]` or `newsrc, =` missing here?

BTW, the 0.9 threshold might be very fuzzy for large terms (copywriting paragraphs), shouldn't we be using a Levenshtein distance here? @xmo-odoo might know of an efficient Python implementation (e.g. the one in [trac.util.text](http://www.edgewall.org/docs/trac-trunk/html/api/trac_util_text.html#trac.util.text.levenshtein_distance))