Refactor settings initialization and access

Current approach to initialize and access settings has multiple problems:

1. Bad performance. Calling Settings::Manager::getFloat and similar functions involves string parsing via std::stringstream. This usually leads to using static which creates problems if we want be able to change settings and reuse new values during process lifetime.
2. Setting name and type are not bound. The knowledge of which type setting has is stored only in the documentation:

Settings::Manager::getFloat("swim upward coef", "Game")
Settings::Manager::getDouble("swim upward coef", "Game") // Does not break anything but is not intended
Settings::Manager::getInt("swim upward coef", "Game") // Also will work
Settings::Manager::getString("swim upward coef", "Game") // Ok, getFloat calls getString anyway

3. Setting value is parsed only when first time used. If there is invalid value user will know only when corresponding code branch will be executed during gameplay.
4. Validation usually happens after Settings::Manager::get* is called. This may lead to duplicated or inconsistent validation.

Ideally by the time setting is accessed it should be parsed, validated and truncated to appropriate value. The type should be obvious from the code. Read should be possible via single read from memory. No function calls should be involved. The interface should be very fast to compile because it's included all over the engine.