Target syntax is not set on the transformation context when the document content is executed

Anca Luca I'm not confident we should cherry-pick, given that this has lead to a regression XWIKI-22923 and that I had to avoid a regression when fixing this issue by removing the outputSyntax=plain from some PDF export requests. It seems there are cases where we used to pass outputSyntax=plain to an async request even if it wasn't really needed (e.g. because the response was written directly to the response body), without any effect, but now this has changed and there is a significant effect.

• In the case of the PDF export, the PDF export job runs in a background thread with a "fake" context that replicates the context from the request that started the export job. The output syntax is also preserved from that request. So if the request that triggers the export has outputSyntax=plain then the exported content is rendered as plain text. Fortunately, the outputSyntax=plain wasn't really needed, because the request that triggers the export returns a JSON that is written directly to the response body (to avoid executing rendering transformations on that JSON).
• In the case of XWIKI-22923, the problem was that the edit confirmation message was obtained in two steps, first parsing (& evaluating) a Velocity template into a RawBlock and then rendering this raw block. When outputSyntax=plain is present, the syntax of the raw block is set to Plain 1.0, so the HTML from the Velocity template is lost when the raw block is rendered. Again, fortunately outputSyntax=plain wasn't really needed because the async request to fetch the edit confirmation message returns a JSON that is written directly to the response body.

I'm worried that there may be other cases where outputSyntax=plain is used but not needed, and the behavior has changed after this issue was fixed.