Changes

Make `failed_to_produce_diagnostic` non-fatal

Remove `diag::type_of_expression_is_ambiguous`

This is a diagnostic that is only really emitted as a fallback when
the constraint system isn't able to better diagnose the expression.
It's not particulary helpful for the user, and can be often be
misleading since the underlying issue might not actually be an
ambiguity, and the user may well already have a type annotation. Let's
instead just emit the fallback diagnostic that we emit in all other
cases, asking the user to file a bug.

Promote LifetimeDependenceMutableAccessors and InoutLifetimeDependence to language features

These were added to guard specific source code in swift interface files for older compilers.
They do not guard any experimental language feature specifically.
Turn them on by default to prevent unnecessary flags developers need to add in their configs.

Restrict existential test to just built

[Embedded] Introduce a test for @_implementationOnly + @_neverEmitIntoClient

In Desktop Swift, @_implementationOnly imports allow one to hide the
implementation so long as you're careful to only reference entities
from the imported modules in code that gets compiled into the object
file and *not* referenced by the corresponding Swift module file.

Until very recently, there was no such affordance for Embedded Swift,
because all functions would have their SIL serialized to the Swift
module file. Using them from a client module would then attempt to
deserialize the SIL, loading the @_implementationOnly-imported module
and causing the compiler to abort. With the introduction of
@_neverEmitIntoClient, we now have a way to say "only in the object
file, never in the module file" for the definition of functions.

Introduce a test that makes sure @_implementationOnly +
@_neverEmitIntoClient has the desired effect of hiding the imported
modules from clients. It's still brittle and hard to use, just like
the existing @_implementationOnly, but this shows that it's at least
possible to do this implementation hiding in Embedded Swift.

Improve differentiableMap vjp performance (#83807)

Improve differentiableMap vjp performance by reserving capacity for the values and pullbacks arrays.

Allow multiple language services to handle a single document

This allows us to implement all of `doccDocumentation` in `DocumentationLanguageService`. `DocumentationLanguageService` will be a secondary language service for Swift files and can also provide the docc documentation support that’s currently in `SwiftLangaugeService`.

Stop launching language service for a language if one fails

If a language service fails to start, don't try starting language services with lower precedence. Otherwise we get into a situation where eg. `SwiftLanguageService`` fails to start (eg. because the toolchain doesn't contain sourcekitd) and the `DocumentationLanguageService` now becomes the primary language service for the document, trying to serve documentation, completion etc. which is not intended.

Handle documentation requests for Swift files in `DocumentationLanguageService`

This cleanly separates the responsibilities for handling documentation from those of handling Swift files. It also simplifies providing docc support for clang because we just need to implement the two `symbolGraph` methods in `ClangLanguageService` and can re-use the remaining infrastructure from `DoccLanguageService`.

Make `LanguageService` initializer non-failable