In "get<lang>DirectiveName(Kind, Version)", return the spelling that
corresponds to Version, and in "get<lang>DirectiveKindAndVersions(Name)"
return the pair {Kind, VersionRange}, where VersionRange contains the
minimum and the maximum versions that allow "Name" as a spelling. This
applies to clauses as well. In general it applies to classes that have
spellings (defined via TableGen class "Spelling").

Given a Kind and a Version, getting the corresponding spelling requires
a runtime search (which can fail in a general case). To avoid generating
the search function inline, a small additional component of
llvm/Frontent was added: LLVMFrontendDirective. The corresponding header
file also defines C++ classes "Spelling" and "VersionRange", which are
used in TableGen/DirectiveEmitter as well.

For background information see

https://discourse.llvm.org/t/rfc-alternative-spellings-of-openmp-directives/85507

Use the spellings in the generated clause parser. The functions
`get<lang>ClauseKind` and `get<lang>ClauseName` are not yet updated.

The definitions of both clauses and directives now take a list of
"Spelling"s instead of a single string. For example
```
def ACCC_Copyin : Clause<[Spelling<"copyin">,
                          Spelling<"present_or_copyin">,
                          Spelling<"pcopyin">]> { ... }
```

A "Spelling" is a versioned string, defaulting to "all versions".

For background information see

https://discourse.llvm.org/t/rfc-alternative-spellings-of-openmp-directives/85507

The code in DirectiveEmitter that generates clause parsers sorted clause
names to ensure that longer names were tried before shorter ones, in
cases where a shorter name may be a prefix of a longer one. This matters
in the strict Fortran source format, since whitespace is ignored there.

This sorting did not take into account clause aliases, which are just
alternative names. These extra names were not protected in the same way,
and were just appended immediately after the primary name.

This patch generates a list of pairs Record+Name, where a given record
can appear multiple times with different names. Sort that list and use
it to generate parsers for each record. What used to be
```
  ("fred" || "f") >> construct<SomeClause>{} ||
  "foo" << construct<OtherClause>{}
```
is now
```
  "fred" >> construct<SomeClause>{} ||
  "foo" >> construct<OtherClause>{} ||
  "f" >> construct<SomeClause>{}
```

There were 3 different functions in DirectiveEmitter.cpp doing
essentially the same thing: taking a name separated with _ or whitepace,
and converting it to the upper-camel case. Extract that into a single
function that can handle different sets of separators.

The class "ClauseVal" actually represents a definition of an enumeration
value, and in itself it is not bound to any clause. Rename it to EnumVal
and add a comment clarifying how it's translated into an actual enum
definition in the generated source code.

There is no change in functionality.

Remove most redundant function calls. Unify enum identifier name
generation (via getIdentifierName), and namespace qualification (via
getQualifier).

Remove extraneous qualifications from names when
- the name is explicitly enclosed by corresponding namespaces, and
- the name is in a body of a function defined in corresponding
namespaces. Otherwise add missing qualifications.

This applies to individual sections of TableGen output, and makes name
lookup independent of the context in which these sections are included.

The official languages that OpenMP recognizes are C/C++ and Fortran.
Some OpenMP directives are language-specific, some are C/C++-only, some
are Fortran-only.

Add a property to the TableGen definition of Directive that will be the
list of languages that allow the directive.

The TableGen backend will then generate a bitmask-like enumeration
SourceLanguages, and a function
  SourceLanguages getDirectiveLanguages(Directive D);