feat: store sites that are rendered on the frontend

[pipoprods]

Q	A
Bug fix?	yes
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes/no
Documentation	no
Translation	no
CHANGELOG.md	no
License	MIT

closes #6737

This adds single-file-proxy integration.
The proxy will render sites in a headless Chromium, returning the resulting page content. This makes Wallabag able to store sites that are rendered in JS.

Two operating modes (in parameters.yml):

1. Proxy only sites that are defined in a given list:

    single_file_proxy_url: https://single-file-proxy.your-domain.tld
    single_file_proxy_all: false
    single_file_proxy_sites_to_proxy:
        - https://www.blast-info.fr
        - https://www.arretssurimage.net

2. Proxy all sites:

    single_file_proxy_url: https://single-file-proxy.your-domain.tld
    single_file_proxy_all: true
    single_file_proxy_sites_to_proxy:

The proxy itself will only process sites that are defined in his own whitelist. It will HTTP Redirect others.
It seems safe to proxy all (only drawback is the external dependency for overall operation of Wallabag).

Questions to team:

1. I've added no test. Could you point me to where I should add them?
2. I've added no doc. Same question as above ;)

[j0k3r]

About tests: maybe you can add one more job into https://github.com/wallabag/wallabag/blob/master/.github/workflows/continuous-integration.yml where you choose one version of PHP, install/enable/run single-file-proxy

About the doc, it'll be at https://github.com/wallabag/doc but maybe you can wait for the PR to be ok before starting writing the doc.

[j0k3r]

Same comment about app/config/parameters.yml.dist

[shtrom]

Would it be better as an application-level config, something like the Site credential management?

[j0k3r]

Of course

[pipoprods]

This point remains unfixed. I'll have a look at this app-level integration now.