9.0 refactor py3o lmi

[lmignon]

The code is not yet functional but I make a PR to share what I'm doing to improve the modularity of custom parser...
IMO we should also replace thee the rml_parse instance as parser context by a new one since it's written for the old api and has a lot of useless methods..
@faide @alexis-via your advices/comments are welcome.
I'll squash the commit once the work will be done

[lmignon]

@faide @alexis-via This PR is ready for review and works fine.... IMO I've improved a lot the modularity of this module and it's now easy to extend the parser to for exemple post process the generated document....
A new enhancement is when the generation is launched from a list of selected items, if the expected format is not pdf, the generated reports are returned in a zip file.

[lmignon]

@faide I've improved the memory consumption a lot when generating a lot of reports

[JonathanNEMRY]

👍

[lmignon]

@alexis-via @faide What do you think about this refactoring? We have more and more client using this code in production and we've started to extend the module based on this new design to provide an alternative way to store the generated report.

[faide]

I like it :p

[lmignon]

@faide I'll also include acsone@4048c0b (v10)
to improve the extensibility of the way to get the template

[faide]

Ok.
I added a small comment to acsone@4048c0b

[lmignon]

@faide Ok I'll fix It. Thank you for the review

[lmignon]

@faide The last commit is the back port of the last changes into the 10.0 OCA#78 Therefore 9.0 and 10.0 are equals on a functional point of view.

[lmignon]

@faide @alexis-via I've experienced a lot of troubles in case of errors when generating a py3o report. (screen lacked in 'waiting' with FF, csrf errors with Chrome). To avoid these errors I had to implement a dedicated web controller to correctly handle the errors and return a response to the web client into the expected format. I don't know if it's the best solution nor the right way to fix this problem. Nevertheless the code can be found here https://github.com/acsone/reporting-engine/commits/9.0-refactor_py3o_controller-lmi (acsone@efccf5c)
These changes makes report_py3o no more compatible with report_custom_filename. Therefore I've developed a glue module.. https://github.com/acsone/reporting-engine/commits/9.0-report_py3o_custom_filename-lmi