refactor: use a configure interface for settings

[6543]

I remain unconvinced of the wisdom of moving more things in to setting and in fact intend to make a refactor that will require mostly reverting this.

We should be using a Configure interface e.g.

setting.Configure(setting.Configurable) error

so that the explicit dependency on setting everywhere can eventually be dropped.

Originally posted by @zeripath in #15241 (comment)

[6543]

my thoughts: of now it's convinient to just have to look to one place if you search for settings or like to change gitea behaviour
if we going to split setting into it's related modules and move it into that modules, we should considder carefully how to do so and what conventions we follow
so we still know without thinking where to look at / put code at

cc @lunny

[lunny]

I think they are different designs. One is to keep all settings on one package(setting), another is to keep configurations on feature packages. Both them have advantages and disadvantages.

We could discuss what's the benefit to convert one to another.

[6543]

I'm fine with both as long as you can easely find related things in codebase

[lunny]

I think #18058 will fix this partially.