Pass environment config to the publish action to harden our releases.

Upon approval I will also update the publish settings on pub to require this environment.

(see https://dart.dev/tools/pub/automated-publishing#hardening-security-with-github-deployment-environments)

Spawned from discussion [here](#3555 (comment)).

- Adds a builder in build_resolvers which emits a file containing the transitive digest of the library and all its imports.
  - When computing the transitive digest, we always first look for transitive digest files next to all of our immediate library deps, if they exist we merge that file into our digest and don't crawl any deeper.
    - If we can't read any transitive dependency for some reason we emit a warning and just give up in the builder, which means we will never emit a transitive digest file for that library (which is fine, just not optimal).
- The resolver reads these files to establish dependencies - for each library dependency we first check for a transitive digest file, if it exists we just read that and don't crawl that libraries deps. If it doesn't exist then we do the old behavior.
  - There is actually an additional step here that will continue the recursive crawl for libraries that have not yet been seen in order to load them into the resource provider for the analyzer.
- I also exposed a shared resource to avoid duplicate parsing of libraries between the resolver itself and the transitive digest builder. We might eventually want to migrate this to a builder as well, and serialize that information to disk instead, which would avoid some unnecessary re-parsing of libraries on rebuilds.

This is cleanup work required to start enforcing this with static analysis, as per dart-lang/sdk#53253.

Real quick this issue is that this code is unsafe:

```dart
void f(Completer<int> c, int? i) {
  Future<int>.value(i); // Ouch!
  c.complete(i);        // Ouch!
}
```

- Thanks for your contribution! Please replace this text with a description of what this PR is changing or adding and why, list any relevant issues, and review the contribution guidelines below.

---

<details>
  <summary>Contribution guidelines:</summary><br>

- See our [contributor guide](https://github.com/dart-lang/.github/blob/main/CONTRIBUTING.md) for general expectations for PRs.
- Larger or significant changes should be discussed in an issue before creating a PR.
- Contributions to our repos should follow the [Dart style guide](https://dart.dev/guides/language/effective-dart) and use `dart format`.
- Most changes should add an entry to the changelog and may need to [rev the pubspec package version](https://github.com/dart-lang/sdk/wiki/External-Package-Maintenance#making-a-change).
- Changes to packages require [corresponding tests](https://github.com/dart-lang/.github/blob/main/CONTRIBUTING.md#Testing).

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.
</details>

Closes #3428.

I am trying to see if we can re-enable the markdown checker as well (I just re-enabled the workflow).

Fixes #3343

Fixes #2150

Fixes #2995

When the summary file is determined to be invalid, regenerate it and
overwrite it without deleting. This resolves a race condition where
multiple resolvers could try to delete the same file. The invalid
content will not be read, because we will regenerate the file before
moving on to the rest of the build.

…rect behavior (#3580)

Deprecate the unnamed AnalyzerResolvers constructor, replace it with a static instance getter and `AnalyzerResolvers.custom` factory constructor.

These new APIs guarantee a 1:1 relationship between the BuildAssetUriResolver and an analysis engine, which is necessary to ensure `changeFile` is always called on each analysis engine when needed.

Note that the deprecated constructor does not uphold this invariant, it remains backwards compatible with its old implementation, and uses the same BuildAssetUriResolver as the shared resolver.

Related to dart-lang/source_gen#682.

Deleted files were never getting a changeFile call and so they were still available in the analyzer. This exposed in particular old generated part files to subsequent builds which could cause weird errors.

Remove some references to the behavior of older versions of build_runner
and build_resolvers. The changes were made in 2020, and we have had a
major version change since the version which introduced the change.

Change some docs about compatibility with older build_resolvers to
instead describe the utility of splitting steps for improved
invalidation behavior.

…ace dir (#3608)

Also adds a dependency on package:crypto

Also bump min SDK
Also prepare for release