Introducing syntax tables, making EWG30 more evident through them.

The most glaring flaw of my initial draft was to overestimate the zeal with
which C++ standard committee member would reason about annotation. A new
section on annotation is introduced that deals with just the rules and uses
two tables for showing various combinations of integral constant expressions
with annotation. This will supplant "Pack annotation semantics" which may
be heavy and repetitive to read.

Most importantly, EWG issue 30 is now readily evident as directly addressed.
I have used the term "access annotator" for the individual accessor, which
was my old term. The "access annotator" is a degenerate form of the "interval"
annotator, but lacking any connection to the triple-dot operator used with
packs as we know them today. It offers access by index.
Removing some more cruft, priming for "formal" addendum.

No conceptual changes right now, just some generic rearrangements. It
should be enough for changing the "formalness" everybody dislikes but
is important to reason through into a better form in the addendum.
Deployment scenarios should be moved prior to that and immediately after
annotation rules and their syntax table examples.
Expansion enhancements, 2-expression access annotation and triple-dot.

This helps go straight into "ternary" for which I still have to find a
better term. The interesting interplay with triple-dot and the interval or
access annotator is quite interesting because it allows full expression
semantics to be terse and precise in their contextual meaning. More work
is needed to clarify and shorten this.
Removed the "individual accessors" from inclusion.

The rationale is that the term is getting supplanted by "access annotators"
which of course do not require to be defined as degenerate forms of the
"interval annotator". Everything in that removed section can be rewritten
in much simpler form.
Some forms of the access annotator.

Practically, for a pack that has been declared as ...T we have:

     T{N}     = access parameter at index N
     T{N,M}   = expand all parameters within [N,M) indices.
     T{N}...  = T{N,sizeof...(T)}

Some clarifications and analysis of the pattern interaction and then we
should be likely done releaving it from the interval annotator, which now
has a very straightforward meaning.
More access annotation clarifications!
Rules and syntax of annotation in a single section.

After removing equivalent form examples from syntax tables and clarified what
access annotation is all about, it becomes easier to express everything that
annotated template parameter packs are within a single, dense section. This
makes examples coming after less verbose to explain since the table can be
used as continuous reference.

Also, started deprecating the term "anchored" and "anchoring" over "access"
in expansion and single-expression "interval" in declaration. It needs a
little more care, but it is getting there. Issues #9, #10 are related.
Merging syntax table examples and accessors together.

Worked out syntax table examples so this is an easy merge.
Some fixes in the syntax table.

Let's remove what is "trivial to explain" because it would hurt the
explanation itself and explain it in simpler terms. Still some errors
are visible in the explanation of the text and table, should work
more on this.
More stuff from interval and access separated better.

At least in the syntax table.
Better way of specifying semantics in the syntax table.

Got rid of all equivalent forms in the syntax table for now, better way of
explaining what annotation does has been written in the 'Significance' column.
Removed a pointless and dangerous shorthand

There is no need and point for the access annotator to be followed by
triple-dot when we want to expand from a given index to the end
of the pack since this can be done through T{N,sizeof...(T)}. Such
a triple-dot addition would make things ambiguous with non-type
parameters for no good reason. Indeed, commit bdb29d2 did not have this
and neither should it exist.
Changing the names of the annotators.

The following terms substitute the previously used ones for annotators:

   1) "size  annotator" substitutes: "interval annotator"
   2) "tuple annotator" substitutes: "pattern annotator"
   3) "range annotator" substitutes: "access annotator"

The reason for this change is that it becomes easier to explain what the
annotators do because the interval annotator made a size-based match over
and inverval of sizes, with the access annotator expanding to the ordered
sequence of types within specified index bounds. Both should thus be
considered as 2-expression based degenerating into 1-expression based
annotation when we degenerate from intervals of sizes and types to
a specific size or type. This can really shorten the text for what this
draft actually discusses.

The tuple annotator practically has the effect of providing a check on
whether a pack is a tuple of pack whose size is sizeof...(T)/K where K
is the integral constant expression of the annotator previously known
as "pattern annotator".

Other changes included removing some sections that need no longer be in
such form, especially with the "formal" part which despite correct, was
quite boring for "learn by example people". It will make a comeback
later on in the addendum.

Fixes #12, fixes #9, fixes #7 due to issue deprecation and renaming.
Merged annotator clarifications and restructuring.

The document gets slimmer, gets a syntax table for annotation, the names
of the annotators become more descriptive of their actual intent. Some
issues closed.