Add helper scripts for creation of exercises

[pclausen]

Adding create_fotran_test.py and CMakeLists.txt for easier creation of
new exercises.

[SaschaMann]

A few general notes:

• I think these files should be in bin/ and not config/ because they're scripts that you run when working on the track and not config files.
• Running some kind of Python linter helps a lot to keep scripts consistent and to adhere to Python Best Practices. Most IDEs or editors have support or extensions to accomplish this. Makes the code a bit more readable for otherse overall.
• A short comment what each function does would help future contributors figure out how the script works in case they need to debug something.

[SaschaMann]

Some tracks add the problem specs repo as a git submodule, so that it's easier to keep track of the version that was used to generate tests. A git submodule is essentially a reference to another git repo at a certain commit.

I think it's worth considering doing this to make it easier to keep the tests up-to-date if the problem specs change. I can go into further detail on Slack if you want.

[kotp]

Some tracks require that the problem-specification repository be cloned at the same level as the language track.

So:

.                                                                                                                                               
├── automated-mentoring-support                                                                                                                 
├── bash                                                                                                                                        
├── fortran
├── haskell
├── problem-specifications
├── python
├── ruby
├── ruby-analyzer
├── vimscript
├── website
└── website-copy

[pclausen]

hmm, here I am a bit out of my knowledge of git to do this. Seems overkill to me to create a new git sub-repo for a single file(?) But I leave this to you guys to decide.

[SaschaMann]

A submodule isn't a new repo, it's a reference/link to a different repo at a certain commit. In the filesystem it's just a normal directory, but it allows you to refer to a specific version of that repo.

In this case the advantage of adding problem-specs as a submodule is that you could pull the latest version of it and update the exercises to that version and that everyone using the repo is on the same problem-specs version.
If problem-specs is updated after that, it's easy to find out what changed since the last time the exercises were updated, which can potentially make it easier to keep them up-to-date. The C# track does it, you can see what it looks like here: https://github.com/exercism/csharp/.

There are other ways to keep track of the changes to problem-specs, so it depends on your preferred workflow and is mostly a matter of preference.

I brought it up because I personally like that approach but perhaps it's best to ignore it for now and perhaps revisit it later once you have more experience with git and know what works better for you.

[kotp]

Let's adopt the "One sentence per line" where we can for this track. It will make diffs clearer, while our editors can likely wrap to the desired line length locally for lines that are "too long".

It makes corrections easier, diffs less noisy, commits won't involve sentences that it doesn't need to, etc.

I have provided a small set of changes regarding the "One Sentence Per Line", but there are other things that need to be changed as well.

[SaschaMann]

LGTM. This should probably be merged using "Squash and Merge" to create a single commit instead of having 13 individual ones.

(Best to wait for @kotp's approval, though)

All changes integrated