A user reported that beautification was strange inside of a block
construct, specifically with an instantiation. As it turns out there were
multiple issues. First, in syntax, the block construct required the ending
label and this is technically optional, so I made the syntax close correctly
when a block does not end with its label. The opening label for a block
IS mandatory per the LRM however.

Secondly, the instantiation beautification error was due to the fact that in a
block the generic map construct ends differently than anywhere else. I'd
done a trick with the beautification engine where it ignored generic map in
lieu of generic because of that difference in ending structure. The
example provided by the user had a generic map in the instantiation so
it was ignored and strange things happened with beautification. I created
a branching structure in the beautification engine for block (as I've done
for other lexical structures) so generic map no longer gets ignored in the
concurrent section.

A reminder about block usage and syntax. The LRM does indicate the is
is an optional word however for my purposes it is not optional. block
may have a guard expression and I need a delimeter to mark the place between
the guard expression and the declarative region. I believe I put in a
snippet for this for a prior issue and put the is in there.

I think I've got case/when alignment structures more or less sorted out and
no one had to die or anything this time around. Assignments followed by
positional arguments should align correctly in that order most of the time,
and then when choice => should align correctly followed by assignments on
those lines. Hopefully that settles the matter once and for all, but I'll
take another crack at it if something goes pear shaped.

Just a note, all you folks who are putting a ton of things on the same
when choice => line for compactness, there is a limit to this and I think
I've reached it. If you are getting beautification results you don't like
because you've put entire paragraphs on the same line after a when choice =>
just put it on the next few lines please. Your code maintainer will thank
you someday (or at least won't curse your name overmuch.)

Added basic support for aggregate assignment. The location of this paren
group is in a tricky spot (due to the way the syntax file is setup looking
for lexical contexts) so it really is just basic support. I don't think
symbols or identifiers inside the paren group will scope as finely grained
as in other places in the code, but at least it won't flag as an invalid
closing paren anymore. I might be able to get something more sophisticated
in place with more experimentation since this might be the only VHDL construct
that starts with opening parenthesis.