Add fine-grained control over how the headless Chrome is accessing XWiki

When performing the PDF export on the server-side, using a headless Chrome (either remote or running inside a Docker container), the browser needs to access XWiki, but it cannot always use the same URL as the one triggering the export, e.g. because XWiki is behind some front-end / proxy. The export.pdf.xwikiHost configuration property can help in this case but it may be a bit limited:

• you can't use a different scheme / protocol (e.g. use HTTP instead of HTTPS when bypassing the front-end / proxy)
• you can't use a different port (e.g. 8080 instead of 80)
• you can't specify some custom headers (e.g. to bypass / satisfy some authorization)