Add X-Cache-Enabled HTTP header

[strarsis]

This PR adds the X-Cache-Enabled HTTP header to nginx responses. It will not be added when upstream cache status is BYPASS as then no caching is used for the request.

WordPress Site Health Page Caching uses specific HTTP header values in the loopback HTTP response in order to detect that page caching is indeed enabled.

The related Fastcgi-Cache HTTP header is added by Trellis, but not used by the WordPress site health check.

Adding this to Trellis by default appears to be a good idea (no obvious side-effects, improving compatibility with WordPress core (site health check)).

See roots discussion: https://discourse.roots.io/t/site-health-check-page-cache-not-detected/25640/2

Note: Should this X-Cache-Enabled HTTP header only be added to loopback requests? On the other hand, the Fastcgi-Cache HTTP header is also already added to all requests.

Possible alternative: A Bedrock MU plugin that uses the Fastcgi-Cache HTTP header to set X-Cache-Enabled in PHP code.

[swalkinshaw]

Note: Should this X-Cache-Enabled HTTP header only be added to loopback requests? On the other hand, the Fastcgi-Cache HTTP header is also already added to all requests.

If possible (and relatively easy) I might prefer this just to avoid having "duplicate" response headers. In the long run it might be better to unify on the more generic X-Cache-Enabled header but I'd rather not deal with that breaking change.

🤔 X-Cache-Enabled is a bit of a weird name thinking about it more. It says cache is enabled, but not necessarily if its a cache hit? 🤷‍♂️ X-Cache is the more common header for cache status

Another reason to try and limit this to loopback if possible.

[strarsis]

@swalkinshaw: Ideally the X-Cache HTTP header is also checked in WordPress, but until this is added, X-Cache-Enabled appears to be the least intrusive HTTP header.

Yes, constraining the header to loopback requests only would be a good idea, it should be relatively easy using the map.