Issue 5862: Prefer astyle 3.1 and update clang-format options

https://sourceforge.net/p/testlilyissues/issues/5862/

Change the preferred version of astyle from 2.04 to 3.1.

In a separate commit, add a few clang-format options to reduce
(slightly) the extent of changes that a subsequent fixcc.py makes.

Test procedure:
1. clang-format everything (version 9.0.0)
2. git commit
3. fixcc.py everything (astyle version 3.1)
4. git diff | wc -l

BASELINE                                          LINES
master@786c3669ff08804465a89013d349fc745fd783c9   19702

BENEFICIAL OPTIONS (TESTED INDIVIDUALLY)          LINES
ConstructorInitializerIndentWidth: 2              19062
ContinuationIndentWidth: 2                        15018
SpaceAfterCStyleCast: true                        19540
[Tested together]                                 14171

OTHER OPTIONS (TESTED INDIVIDUALLY)               LINES
AlignEscapedNewlines: Left                        19702
AlignOperands: false                              20760
AllowShortFunctionsOnASingleLine: InlineOnly      19708
AlwaysBreakTemplateDeclarations: MultiLine        19702
BinPackArguments: false                           21588
BinPackParameters: false                          20557
BreakBeforeTernaryOperators: true                 19702
BreakConstructorInitializers: BeforeColon         19702
BreakInheritanceList: BeforeColon                 19702
ColumnLimit: 80                                   19702
SortIncludes: false                               19702
SpaceAfterTemplateKeyword: false                  19702

[Dan Eble, 2020-03-26 01:25:57]

It's worth emphasizing this: even with these improvements to the clang-format
configuration, those who use clang-format will introduce a truckload of
differences from the traditional indentation.

[dak, 2020-03-26 11:35:11]

On 2020/03/26 01:25:57, Dan Eble wrote:
> It's worth emphasizing this: even with these improvements to the clang-format
> configuration, those who use clang-format will introduce a truckload of
> differences from the traditional indentation.

Our own fixcc script introduces some modifications to naked Astyle if I remember
correctly.  Is there some reasonable hope that we could boil down a "common
denominator" style where alternately applying clang formatting and fixcc would
end up with a fixed end result rather than some cycle?  Of course, that state
would trivially be reached by one style doing nothing, or the styles focusing on
different problems, but that would not be useful: we'd want to end up with
either style doing as complete of a job as possible so that people using either
will commit stuff that is mostly fine.

[Dan Eble, 2020-03-26 23:17:17]

On 2020/03/26 11:35:11, dak wrote:
> On 2020/03/26 01:25:57, Dan Eble wrote:
> > It's worth emphasizing this: even with these improvements to the
clang-format
> > configuration, those who use clang-format will introduce a truckload of
> > differences from the traditional indentation.
...
> correctly.  Is there some reasonable hope that we could boil down a "common
> denominator" style where alternately applying clang formatting and fixcc would
> end up with a fixed end result rather than some cycle?

I have not familiarized myself with the options of astyle, but at present, I'm
not optimistic.

Still, as I worked on this change, I noticed a couple of common and simple
things that could take another bite out of the differences:

1. space or no space after the "operator" keyword
2. space or no space after "template" in "template<class T>"