Add support for fallback proxy

[berezovskyi]

After thinking about oslc-op/oslc-specs#458, I tried to get OSLC Browser to work without ignoring CORS. I had to do a few tricky steps but still did not manage to do it because there is limit to how many servers I can update.

First, I had to add CORS filters to oslc-op/refimpl@66527f6. Now, this is not possible to do on an app you don't have code access to but I have some Nginx and Apache HTTPD snippets to duct tape it.

Next, I hit the problem of OSLC CM vocab lacking CORS headers and, finally, I think I would have hit it with DCTerms. I still think it's a critical issue to address. I will keep suggesting OSLC to specify it properly and I am planning to suggest https://archivo.dbpedia.org/ to add ontology "fetchability" in a browser as a 5th star.

Now, I realised that for OSLC Browser to work, we absolutely need a proxy. As opposed to Jazz approach, I am suggesting to:

• use a proxy only as a fallback
• use it only for public read-only resource and demand proper CORS for authenticated and read/write resources.

This PR adds support for a configurable fallback proxy.

OSLC CORS will be fixed in oslc-op/website-content-negotiation#8

[berezovskyi]

Spec: https://github.com/berezovskyi/corsherdf#spec

Example resolving resources from CM RefImpl server (no fallback request needed) and OSLC CM vocab (fallback to the proxy) and no security CORS disabled:

[berezovskyi]

cc @jamsden @jadelkhoury @ndjc

[berezovskyi]

also cc @axelreichwein in case you needed a proxy like this too and we can work on refining a common RDF proxy spec

[berezovskyi]

Partly solved in #36 by using https://cors-anywhere.com/

My CORSheRDF project is a bit far from being ready to be exposed to all the abuse such proxies typically get.