Context

drivers-evergreen-tools is consumed three inconsistent ways: configure-env.sh clones it fresh into a sibling directory on every Evergreen run, create-spec-pr.sh assumes that same sibling clone exists, and local dev setup asks contributors to clone it manually and export DRIVERS_TOOLS themselves. The GitHub Actions workflow also references mongodb-labs/drivers-evergreen-tools@master, an unpinned ref that semgrep already flags.

A pinned submodule removes all of this: contributors no longer need to set DRIVERS_TOOLS by hand, CI stops re-cloning an unbounded upstream repo on every run, and an unpinned @master reference can no longer break our build the moment drivers-evergreen-tools cuts a new release.. We can also unconditionally use drivers-evergreen-tools in our scripts rather than having the current limitations and workarounds.

Node follows a similar pattern: https://github.com/mongodb/node-mongodb-native/blob/main/.gitmodules, and also https://github.com/mongodb/mongo-php-driver/blob/v2.x/.gitmodules.  They use dependabot to update the version.

Definition of done

* drivers-evergreen-tools is a git submodule of the repo, initialized by just install.
* configure-env.sh and create-spec-pr.sh use the submodule checkout instead of cloning a sibling directory.
* Local dev instructions no longer tell contributors to clone drivers-evergreen-tools by hand.
* The GitHub Actions workflow pins mongodb-labs/drivers-evergreen-tools to a commit SHA with a version comment instead of @master.
* CONTRIBUTING.md documents how to point the submodule at a different commit for an Evergreen patch, and how to point it at a local checkout instead.

Pitfalls

* The pinned SHA and version comment must match a real tag so dependabot can update it properly.