Change handling of root index.html/"homepage" of PODs that have no meta-tag for `solid-allow-automatic-updates`

A solution for updating root index.html/"homepage" of PODs was implemented in https://github.com/solid/node-solid-server/pull/953. The handling this PR introduced might not be optimal, and we should at explore what can be done.

The PR made it so that when you run npm run solid updateindex the following checks are done:

1. No meta-tag for solid-allow-automatic-updates --> do update
2. solid-allow-automatic-updates is set to true --> do update
3. solid-allow-automatic-updates is set to false (or anything beside true really) --> do not update

As discussed in https://github.com/solid/node-solid-server/issues/951, number 1 should might be handled. The problem is when users have done updates to their index.html and aren't aware of solid-allow-automatic-updates.

A proposed solution to this is to check each index.html with the previous version of index.html, and only update if the index.html we want to update is equal to the previous version (i.e. there has been no changes). This intuitively feels like a good solution.

The problem is which version should we check against?

• The version in config: There's a system that copies over template files to a config-directory upon starting the server. This can represent the last version maintained by the POD provider. But this will probably miss a lot of older accounts created before the last upgraded version; this is a good solution if the script is run after each upgrade of the index.html.
• All previous version: The idea is to have a list of all iterations of index.html, and if the current index.html matches one of them, we know that it can be upgraded. The problem with this approach is that it can get a bit cumbersome to maintain the list of iterations and I suspect at some point it will get very performance heavy to iterate all iterations for all users.

The latter solutions requires maintaining a list of index.html, and I don't think this is a good solution. Both solutions require fetching data about the user to generate the file to check against previous version(s). This will increase the performance cost of running the script.

Performance might not be a big problem since these are scripts that should be run seldomly.

Personally I think this is not going to be a big problem, since users that care enough to customize their root index.html will also care enough to find info about solid-allow-automatic-updates (although I understand it's a custom meta-tag, and might not be easily found).

The biggest problem I have with simply updating the file is that it kind of violates the sovereignty of the POD. But I think this is OK for most users, and those who aren't ok with that have a mechanism to prevent it. So although it's philosophically a bit "on the edge", I favor the solution for its pragmatic reasons: I assume most people want to have their "homepage" auto-updated by default. (But, as always, I'm very much open to be challenged and convinced otherwise on this.)