Add Settings Extender

[SychO9]

Part of #1891

Changes proposed in this pull request:
Add an extender to expose settings to the frontend through the ForumSerializer.

Reviewers should focus on:
Naming:

• Class: Settings ? Setting ?
• method: modifier ?

Confirmed

• Backend changes: tests are green (run composer test).

[askvortsov1]

A few more nitpicks, but other than that, I really like this one!

[askvortsov1]

So I've been thinking more about this, and I'm no longer as sure as I was before. Sorry for the confusion and back-and-forth. The thing is, we already have a default settings mechanism: adding those values to the DB via a migration, which feels a bit faster. This new mechanism is more convenient, and makes sense, but I'd like to have a little bit more discussion, if only for the sake of devil's advocacy, before we implement it. How would you feel about splitting the default settings portion of this out into another PR (so this one only adds serialization), and revisiting the default part for beta 16? Sorry again.

[SychO9]

🤦 I completely forgot about migrations. Also while updating all bundled extensions I didn't use the default method, precisely because the values were added through migrations.

How would you feel about splitting the default settings portion of this out into another PR (so this one only adds serialization)

I don't even think we need to consider it at all unless we really feel the need to do something like this in the future.

The question is, are we fine with having the whole settings extender class with just the serializeToForum method ? (as far as I'm concerned, it's best this way than having a method in the ApiSerializer class. It's more verbose and clear as to what it is doing).

Sorry for the confusion and back-and-forth

Never be sorry when it comes to what's best for the project :D, I can dance.

[askvortsov1]

The question is, are we fine with having the whole settings extender class with just the serializeToForum method ? (as far as I'm concerned, it's best this way than having a method in the ApiSerializer class. It's more verbose and clear as to what it is doing).

Yeah I think that's good, seeing as we really only want to serialize them to one serializer. If different use cases emerge, we can always reconsider later, but for now I think this is a good solution.