Add external config file in user folder

[smix8]

The games startup properties, debugs and cheats are all stored on nodes and other project commited files.

This means everytime I change them I need to undo all those changes when I want to do a clean commit to not dirty the entire history.

If stuff like "no logo at startup" or debug properties and cheats would be read from a config file in the user folder that could be avoided.

[Scony]

Well, the main idea behind FeatureFlags.tscn and FeatureFlags.gd is to have maximum flexibility and simplicity. The fact that FeatureFlags is a simple, single-noded, and autoloaded scene makes it usable from the editor thus giving flexibility while being a simple solution.

However, I agree that it's fairly easy to commit the temporary changes done to that scene by mistake.

I've been thinking a bit about this, and the only solution I came up with so far is to make FeatureFlags a @tool that would use a resource stored in the user://. The usability would be as good as now, and the solution itself would be just slightly more complex. However, the problem I see is that in this case, it will be fairly easy for the developer to forget about the flag that was changed as there will be nothing indicating the flag X was changed (currently in the editor we will see the indicators allowing one to bring back the default value, while in the repo the changes will be seen on the git level).

There's also one more aspect to the above - security. FeatureFlags in the current form serves as a flexible way to define "build-time options". Having such settings stored in the user:// makes it easier to alter flags - especially on the web platforms. I can imagine scenario where someone crates closed-sourced fork of the project and releases a game. If the FeatureFlags part would use user:// and would be same as in godot-open-rts, it would be trivial to take some customized config file and use with such a closed-source game thus giving the users flexibility that maintainers of the fork would not like to have.

So, unless we have solution to above problems, I think we have no other way than to stick to the current flow where we need to manually git add <file/dir> certain things before git commit -m <msg> to not include changes to FeatureFlags.