Introduce the Vary header when fetching a resource by rev/tag

[imsdu]

Motivation
See #4295

Complex applications (e.g. SBO) in some cases require fetching a lot of interconnected data from KG
either by using SPARQL queries or sets of subsequent calls to ES/resource/file endpoints. 
Such operations might be slow which leads to degraded user experience.

Describe the solution you'd like.
Web clients these days support Cache API which, in the context of SBO, can be efficiently used 
to cache resources/files with fixed revisions, but requires VARY header (the spec, some pretty 
good article) to be present on the HTTP responses in order for 
key matching algorithm to function properly.

I think that a minimal solution would be to have a Vary: Accept header for Resources/Files 
fetch endpoints, so that clients can discriminate between requests for a file or its metadata, 
a resource or it's Web representation/redirect (when using Accept: text/html request header).

This will not only enable efficient caching on the client side, improving the UX, 
but as a side-effect will lower the amount of requests to KG.

Acceptance criteria

1. When a user fetches a resource by rev or by tag then a vary header is introduced with the response with the Accept, Accept-Encoding and Cache-Control headers provided by the client
2. This list of header can be configurable so that other headers may be easily included in the future
3. The fetch original payload follow the same rules