"[A | B]" grouped-union syntax for type tags

[apiology]

Summary

Closes #1699. There was no way to nest a union inside a position where ,
already means something else - most concretely, an order-dependent list's
positional slots (Array(A, B) already means "2 slots", so , can't also
mean "alternative for this slot" there).

[...] is a new, dedicated grouping construct - unlike <...>, (...),
and {...}, it never takes a preceding type name and never means a
collection; [A | B] alone just means "A or B", exactly like the plain
top-level list A, B, but usable anywhere a type is expected. | is only
meaningful inside [...], and , is not allowed inside [...] - the two
never compete for the same position, so there's nothing to disambiguate
(no need for a "cannot mix , and |" rule, or extra nested parens).

This resolves the motivating example from the issue directly:
Array([Integer | String], Symbol) is a 2-element tuple whose first
element is an Integer or a String, followed by a Symbol - no extra
nesting required.

Why [] and not () or reusing ,

• () already has an established meaning (Array(A, B), an
  order-dependent tuple) that this repo isn't changing here, to leave that
  syntax free for a possible future use.
• [ has no meaning at all today in YARD::Tags::TypesExplainer::Parser
  (only <, (, { are wired up as bracket-openers there), even though
  the outer tag-value tokenizer (DefaultFactory::TYPELIST_OPENING_CHARS)
  already balances it generically - so it's free to claim without any
  parsing-level conflict.
• Reusing the existing ,-for-union convention inside the grouping
  brackets was considered and rejected: it would make [A, B] and
  [A | B] two spellings of the same thing, and (worse) invites
  misreading [A, B] as an array/tuple literal by analogy with other
  ecosystems, rather than as a plain 2-way alternative. | avoids both.

What else changed

Also documents three pre-existing (but previously undocumented in
docs/Tags.md) anonymous shorthand forms - <A>, (A), and {A=>B} -
where the leading type name can be omitted and defaults to Array or
Hash respectively. These were already implemented and spec-tested, and
documented externally at https://yardoc.org/types.html, but absent from
this repo's own docs; see #1701.

Test plan

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

[apiology]

Superseded by #1700, which now combines this PR's grouped-union work with the intersection-type PR into a single PR, per review feedback. Closing this one.