Build system: key the website build cache on the input parameters that primarily determine its output (refs: #15342)

As said when I reviewed anonym's initial implementation
(5d07d53a), I was not satisfied by a cache that
came with no automated invalidation mechanism at all, thus leaving up to each
individual developer the "is this weird behavior caused by the cache?" analysis,
and the manual invalidation of the cache.

So, IMO we need to know when we can invalidate the cache, which is equivalent
to: we need to know when a fresh build of the website would yield
a significantly different output. This is what this commit does, by maintaining
multiple cache directories, keyed to the input parameters that primarily
determine the output of the website build. Note that I'm definitely not aiming
for perfection here: for example, I did not list all the ikiwiki
dependencies recursively.

Finally, I'm also moving this cache to a dedicated storage volume, in order to
support caching the website even when not using the 'vmproxy' option:

 - To start with, I don't use 'vmproxy' myself, but I would like to benefit from
   caching the website.

 - Furthermore, once we're confident enough in this caching mechanism, we could
   consider enabling it for our CI builds, that don't use 'vmproxy' either.