Add intersection ("A & B") and union ("A | B" / "[A | B]") type syntax

[apiology]

Summary

Adds three related type-tag syntax elements:

• & (intersection, closes Syntax for intersection types #1644): Foo & Bar means a value must
  satisfy both Foo and Bar, matching Solargraph's syntax
  (Add intersection (A & B), union (|), and grouping ([...]) type syntax castwide/solargraph#1231). Legal in every position a type can appear,
  and always binds tighter than the union or slot separator around it,
  matching RBS's documented precedence. Renders as "both a Foo and a
  Bar" (or "all of a Foo, a Bar, and a Baz" for 3+), to avoid reading
  like two separate values.
• | (union, closes No general grouping syntax for unions nested inside tuples, intersections, etc. #1699): marks a union - a value matching any of
  the listed types. Some type lists already mean a union without it (the
  top level, a hash's key/value lists, [...], and
  Array<...>/Set<...>), so , and | land on the same result there.
  Elsewhere, each comma-separated item is a distinct, positional type
  parameter instead (a fixed-order list like Array(...), or <...> for
  a name other than Array/Set) - there, | groups alternatives
  within a single one of them: Array(Foo | Bar, Baz) is a 2-element
  Array whose first element is a Foo or a Bar, and
  Result<Success | Failure, Other> is a Result whose first type
  parameter is a Success or a Failure.
• [...] (closes No general grouping syntax for unions nested inside tuples, intersections, etc. #1699): used the same way parentheses are in
  algebra, to override the default order of operations - e.g. to use a
  union as one conjunct of an intersection, which otherwise has no way to
  mark where the union ends: [Foo | Bar] & Baz.

Also documents three pre-existing but previously undocumented anonymous
shorthand forms - <A>, (A), {A=>B} - where the leading type name can
be omitted and defaults to Array/Hash (see #1701), and stops
Foo<A, B> from always being read as a union: <...>'s type parameters
are conventionally used both ways - a homogeneous collection's implicit
union of element type(s) (Array<String, Symbol>), or a class's
distinct, positional type parameters (Result<Success, Failure>).
Array/Set (and any name with a single type parameter) keep the union
reading; Hash<K, V> gets its own dedicated key/value rendering matching
Hash{K=>V}; anything else with 2+ parameters reads neutrally ("a Result
with type parameters (a Success, a Failure)"). This choice is made
entirely at render time (CollectionType#to_s) - the parser always
treats <...> the same way it already treats (...), with no
name-specific knowledge at all.

Full rules and examples are in the new "Operator Precedence" and
"Overriding the Order of Operations" sections of docs/Tags.md, and the
rewritten "Parameterized Types"/"Union Operator" sections.

Test plan

• bundle exec rspec spec/tags/types_explainer_spec.rb - specs for
  IntersectionType/GroupType/CollectionType#to_s, parser-level
  precedence/error cases, and end-to-end .explain examples.
• bundle exec rspec - full suite green (2830 examples, 0 failures).

[apiology]

@lsegal this one is ready for review