Add `PROGRAM_MAY_MODIFY_SETTINGS` setting

[delvh]

Problem derivation

At the moment, we always need to delegate config changes to the admins of an instance, and refuse to start otherwise.
The reason for that is two-fold:

1. A settings move might have unintended consequences, so it's better that an admin does it
2. We don't know if we can write to the app.ini or not, i.e. Docker users and Kubernetes users like to use their app.ini read only once it is initialized.

But what if we would know if we can modify the config? Then we could automate a lot of things that are currently impossible.
So, what I'm proposing is the following:

Solution

As a first step to automating config changes, we can add a PROGRAM_MAY_MODIFY_SETTINGS setting (I guess in the default section) that is true by default (the docker image and helm chart would set it to false by default).
It has the following meaning:

• false: No change to now
• true:
  • When INSTALL_LOCK=false, no change to now, so treat it just like false above
  • When Gitea is installed already, Gitea can arbitrarily change the config and persist the changes

Advantages

• Gitea can store the last version that was used to run it. This prevents such problems as we have seen in Storage paths must be unique #26380 as we can pinpoint if an instance is affected by a (critical) bug
• Gitea can perform some admin work automatically by auto-applying simple config item renames (see i.e. Use [git.config] for reflog cleaning up #24958, whose changes could be done automatically then)

[silverwind]

Ideally I would like to see a config override table (simple key-value) being written into SQL because writing into local config will not work properly in distributed setups unless all nodes do it which then presents the problem of coordinating the nodes. It's not something one wants to get into.

Said config override table could be shown on the admin ui and admins could be requested to persist the changed settings in their config. Then, once the config table and config are equal, delete the value from the config table.

[delvh]

Yep, additionally, we already have always write access to the database.
That's another benefit in this case.