Fix blst-verification regression test and update pinned commit

[chameco]

See #1620 for context on this.

Note that this still uses git config to change SSH submodule clones into HTTPS. I'm not sure if there's a great way around this generally. It's often more convenient to use SSH for submodules while developing (e.g. if one wants to push commits from the submodule), while using SSH from Actions, especially inside Docker, will likely involve a lot of cumbersome key management.

I'm marking this as a draft for now because the new checked-out commit still isn't on main of blst-verification.

[chameco]

A complication: on the previously pinned commit, all of the BLST proofs still ran in a reasonable amount of time. Since then, the total runtime for the BLST proofs has significantly increased. Parallelizing only helps so much here; the blst-verification repo's CI breaks things up into a few parallel jobs, the longest of which takes more than 8 hours. While information about breakages or performance regressions in these proofs might be helpful, a multi-hour wait is too unwieldy for SAW's CI.

For now, I'm going to enable only the memory safety proofs and the validation of Cryptol specifications. This should hopefully bring the runtime down to a more reasonable duration. In the future, we should consider running the full proofs periodically in a way that doesn't block development (maybe on Fryingpan?) so that we are aware if things break.

[RyanGlScott]

Things LGTM (after getting the relevant commits pushed upstream, of course). Do open an issue about running the full BLST proofs in a nightly job of some kind, however, so that we don't forget.