Note that we cannot write tests for these at the moment. Passing
```
-enable-experimental-feature DefaultIsolationPerFile
```
to the extractor results in:
```
error: experimental feature 'DefaultIsolationPerFile' cannot be enabled in production compile
```
These are currently added implicitly by the compiler in the context of
`if`/`switch` expressions. In the future, there might be explicit
`then <expr>` statement useful for cases where one would like to add
more than one statement in the branch, to mark what value to actually
use.
See https://forums.swift.org/t/pitch-multi-statement-if-switch-do-expressions/68443
They only appear in an intermediate AST and disappear as soon as the
macro is expanded.
The only way to get these in is to construct an "incorrect" AST, e.g.:
```
let x = #does_not_exist() // MacroExpansionExpr
struct S {
#does_not_exist() // MacroExpansionDecl
}
```
This simplifies several instances of metaprogramming by leveraging
[constraints and concepts from C++20][1]. This:
* gets rid of `std::enable_if` by usage of `requires`, making it more
readable and yield better compiler messages.
* uses `requires` instead of `static_assert` to enforce `TrapLabel`
typing
* simplifies all compile-time tests for validity of a given expression
* uses some standard library concepts where possible
* generalizes and simplifies `SwiftLocationExtractor`
Notice that in order to use the `std::derived_from` concept, `virtual`
inheritance had to be added to the label tags, because diamond
inheritance is a problem otherwise. That's because
`std::derived_from<T, U>` requires that `T*` be convertible to `U*`,
which is false if there are multiple non-virtual inheritance paths from
`U` to `T`. As tags never get actually instantiated, there is no runtime
performance penalty in using `virtual` inheritance.
[1]: https://en.cppreference.com/w/cpp/language/constraints
