New setting structure

Currently, settings are put together in a "flat" manner(they are referred to as "Console Commands"), ie. related settings are sometimes not grouped together, which causes confusion and eats children. If that was not enough, admin commands are mixed in, too, and it's soon going to be a real mess when scripting/modules/other becomes usable. This is why I think commands should be put away from settings (and that's why I wont be talking about admin commands here) and that settings should be organized in a better way.

Goals

 * Structured settings tree (Give the rim(flat!) a break! Hug a tree instead!)
 * Put a line between admin command and setting
 * Ghost settings (allowing a setting to be set BEFORE it gets declared)
 * nSettingItem backward compatibility
 * Attempt making cheating harder (but break compatibility :<)
 * Setting groups (think about the LADDERLOG_WRITE_ ones)

General concept overview
Imagine a big tree. That's the settings tree. You have leafs, containing data, and also, and that's where my metaphor breaks, you have leafs hanging on other leafs(in a directory structure, it would be that folders could be a file AND a folder).

That gets you the idea of it. You can have a setting be a number, a string,, or a list of.

What is a setting and what is not a setting?
A setting stores a value for further use, and should be something that can be simply stored at shutdown and used as-in on next start, server or client, and it has to have effect on the long-term. For example, don't store something that depends on a specific player connected to the server or user stats, while user access level would fine as settings.

User stats
There is already something for this, it was referred to as Statistical Collections Database "stat files" on the rest of the wiki, but doesn't seem to have a wiki article.

Stuff that depends on a specific player
There is indeed nothing for this, but it's coming, I promise! :)

/admin KICK was a console command before, wasn't it? What is it now?
It's an admin command!

Name of a setting
A setting name consists of: Names can be [a-zA-Z], but are case insensitive. Some examples: render.enabled render.window.width resource.repositories policy.spamProtection policy.spamProtection.repeatTime game.rubber game.rubber.pingRubber network.compatibility.customMax From user/admin UI, you can shorten each of these main groups to their first letter, except resource for which we'll use res
 * 1) A main group name: render, game, policy, network, or resource, followed by a dot « . ».
 * 2) Sub-groups, each separated by a dot, then a last dot and the setting's name.

Huh? how can and   both be settings?
That was explained earlier: A setting can also be parent of other settings. The parent setting should normally toggle enabled state(or set a factor, in this case) of the feature.

Why using and not   then?
Because first part can only be a group name, for keeping the main groups clear.