I don't recommend embedding configuration files into the build process. That defeats the whole purpose of changing configuration at runtime. What you could do, is providing hard-coded default values, when the config file can't be found. At least for smaller files.
Concerning when/how to change config files from the application: you usually store the local configuration in RAM. When the user modifies it, it must eventually be saved on hard disk. Now the question is, when you commit those changes. Either directly after a button was toggled (savest, but slow for large configs) or only in special situations, such as when the user leaves a menu (less save, but more efficient).
Concerning file formats: don't overcomplicate things. If you have a relatively flat structure with only few data types (string, number), you can build something on your own with std::fstream. In fact, I would do that anyway, you get a lot of experience about standard I/O and string handling. If you really need flexibility, you can use hierachical format, such as XML, JSON. I personally don't like XML, it's extremely verbose. Lua tables are also an interesting choice, because they are more scalable -- you can not only store data, but also functionality to introduce scripting behavior. One thing to keep in mind is that the Lua interpreter just loads and doesn't save Lua files, so you need either an external serialization library or you do it yourself (shouldn't take too long). LuaBridge is a nice C++ binding.
