Building on top of the parser and operator-precedence parsing library,
introduce a new library that evaluates `#if` conditions against a
particular build configuration. The build configuration is described
by the aptly named `BuildConfiguration` protocol, which has queries
for various build settings (e.g., configuration flags), compiler
capabilities (features and attributes), and target information (OS,
architecture, endianness, etc.).

At present, the only user-facing operation is the `IfConfigState`
initializer, which takes in an expression (the `#if` condition) and a
build configuration, then evaluates that expression against the build
condition to determine whether code covered by that condition is
active, inactive, or completely unparsed. This is a fairly low-level
API, meant to be a building block for more useful higher-level APIs
that query which `#if` clause is active and whether a particular syntax
node is active.

`IfConfigDeclSyntax.activeClause(in:)` determines which clause is
active within an `#if` syntax node.

`SyntaxProtocol.isActive(in:)` determines whether a given syntax node
is active in the program, based on the nested stack of `#if`
configurations.

These were introduced by SE-0212.

This is the last kind of check! Remove the `default` fallthrough from
the main evaluation function.

The `ActiveSyntax(Any)Visitor` visitor classes provide visitors that
only visit the regions of a syntax tree that are active according to
a particular build configuration, meaning that those nodes would be
included in a program that is built with that configuration.

The operation `SyntaxProtocol.removingInactive(in:)` returns a syntax
tree derived from `self` that has removed all inactive syntax nodes based
on the provided configuration.

Postfix `#if` expressions have a different syntactic form than
other `#if` clauses because they don't fit into a list-like position in
the grammar. Implement a separate, recursive folding algorithm to handle
these clauses.

…lt types

The optional return was used to mean "don't know", but was always
treated as false. Instead, make all of the result types non-optional,
and allow these operations to throw to indicate failure.

While here, drop the "syntax" parameters to all of these functions. We
shouldn't be working with syntax inside the build configuration.