Run py-fuzzer with --profile=profiling locally and in CI

[AlexWaygood]

Summary

Following #20962 we're seeing the fuzzer take much longer in CI on seed 742 than on any other seed (#20962 (comment)). But this problem is only reproducible in debug builds, so this doesn't seem like an issue that's worth worrying much about.

This PR switches the fuzzer CI job to use --profile=profiling, and also makes this the new default if you run the fuzzer locally. This should mean that the build the fuzzer uses in CI has more similar performance characteristics to a release build. This in turn means we don't have to constantly wonder whether the fuzzer taking twice as long is indicative of a "real" issue or just an artifact of debug-build weirdness.

As well this, this also reduces the amount of time the fuzzer CI job takes (4min30s -> 3min40s) and reduces the amount of time we need to wait for the fuzzer job to start. (Prior to this PR, you had to wait for the cargo-test-linux job to finish before it would even start, because it reused the build uploaded from that job.)

Test Plan

CI on this PR

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[AlexWaygood]

this is all basically copied-and-pasted from

ruff/.github/workflows/typing_conformance.yaml

Lines 63 to 78 in 79a0271

	# Build the executable for the old and new commit
	(
	cd ruff
	echo "new commit"
	git rev-list --format=%s --max-count=1 "$GITHUB_SHA"
	cargo build --bin ty
	mv target/debug/ty ty-new
	MERGE_BASE="$(git merge-base "$GITHUB_SHA" "origin/$GITHUB_BASE_REF")"
	git checkout -b old_commit "$MERGE_BASE"
	echo "old commit (merge base)"
	git rev-list --format=%s --max-count=1 old_commit
	cargo build --bin ty
	mv target/debug/ty ty-old
	)

and is also similar to what mypy_primer does.