Restore test file format

[AirQuick]

This pull request derives from #317. So needs to be handled after that.

---

.xspec files in the repository have experienced unrelated format modifications in these few years.
So it's hard to see what the actual changes are.

This pull request restores the original format of these files:

• test/generate-tests-utils.xspec
• test/generate-x-utils.xspec
• test/generate-xspec-tests.xspec
• test/unit-expect-xsl.xspec
• test/xspec-focus-2.xspec
• test/xspec-rule.xspec
• test/xspec-variable.xspec
• test/end-to-end/cases/xspec-focus-1.xspec
• test/end-to-end/cases/xspec-function.xspec
• test/end-to-end/cases/xspec-import.xspec
• test/end-to-end/cases/xspec-imported.xspec
• test/end-to-end/cases/xspec-pending.xspec
• tutorial/escape-for-regex.xspec

Now you can clearly see what has actually changed in those files.

[AirQuick]

The latest automated tests were not submitted successfully. (Maybe I pushed the last commit too quickly.)
They are successful on my repository: Travis, AppVeyor

[cirulls]

@AirQuick: I tried to trace the failed build in AppVeyor or to trigger manually the webhook in GitHub but without success. I wonder if you could push a dummy commit to the branch of this pull request to re-trigger the test build on AppVeyor, this should turn the checks into green. Since we are always doing squash and merge into master the dummy commit should not add junk in your branch.

If you have a better idea to turn the AppVeyor check into green, feel free to share it.

[AirQuick]

Thanks @cirulls , your idea has made this pr green again.

[AirQuick]

@cirulls
Now merged.

@galtm
#475 now conflicts with the master.
As described in the initial comment, this change pertains only to format. Nothing in xspec-variable.xspec has been changed in essence.
Hope you can resolve the conflict easily honoring the restored format.

[galtm]

I should have some time today and/or over the weekend to catch up on your recent comments.

[cirulls]

@AirQuick: thanks, I added this to the release notes.

I think I am party responsible of weird formatting on some files. Just out of interest and for future commits: do you use the automatic format and indent in oXygen to format files before committing them? Or do you have any rules for formatting files (e.g. tabs, number of spaces, etc.)?

[AirQuick]

Formatting wasn't weird and I think it's fine to change it occasionally (inserting some spaces, wrapping too long grew lines).
The problem was that formatting changes were intermingled with actual changes, which made it difficult to see the actual history from 5105319. I was so puzzled that I had to restore the original format before proposing further changes.

I usually use the automatic formatting on oXygen and do so when I make initial commits (because this repository hasn't established any rule yet) or modify a file which was first created by me (because I know its initial automatic formatting rule) or refactor a file broadly (because the changes are disruptive anyway).
When I just modify an existing file which was first submitted by other people, I refrain from the automatic formatting because doing so makes it difficult to track actual changes.

At some point in future we may want to

1. establish our formatting rule based on oXygen's automatic formatting options (just because oXygen appears to be the most popular)
2. create an oXygen project file (xspec.xpr?) and put it in the repository root (and beautify it? - I have no experience with it)
3. set the project level options to realize the automatic formatting rule
4. enforce the automatic formatting on new files submitted to this repository
5. apply the automatic formatting to some of the existing files when they are considered very stable

[cirulls]

This sounds like a good plan although it may take some time to implement it and enforce it via the CI systems. I created #515 to record this conversation in an issue.