I disagree with the "make it as easy as possible" answers to this question.
Options 1 and 2 lock you into something you will have a hard time changing later on. For example, you will find that if your number of parameters grows, you will want to put them into sections and subsections because that makes it simpler to organize. But your syntax doesn't allow this. This is why Microsoft Windows configuration files have these weird
[section] markers -- but they neither really help to clarify sections (because there is no 'end-section' marker) nor do they allow nesting. In other words, Windows configuration files are a great example of "well, dang, shoulda thought of that some more up front". (Of course, that's sort of a running theme with many Microsoft features.)
So, don't do it, you will regret having gone this way and keep inventing strange workarounds to do things you wish you had considered beforehand.
Option 4, on the other hand, is great if you have a machine write the file, but not if a human is doing it. People have tried writing scientific software where the input files are created by hand and have XML format -- I've been on the board of an organization that did that, and it was a complete disaster because people rebelled: XML is simply not readable nor writable for humans.
That only leaves you with option 3. Whether you choose JSON or something that is easier on the eye but has otherwise the same expressiveness does not matter that much. But it should be human readable, human writable, and have some sort of syntax. It should also be pretty self-explanatory what an input file wants to say, which is neither true for your option 1 nor 4. Finally, it should be relatively straightforward to implement in your code, which calls for something for which there already is a parser.