ci: rm the lock file testing

[aignas]

This was not something that turned out to be useful and it is causing enough
friction that it makes it not worth it.

Summary:

• remove presubmit checks checking lockfile
• remove the pre-commit hooks for lock file updating
• remove the note about the lock file
• remove the MODULE.bazel.lock

[fmeum]

@aignas Anything you learned from these checks that we could use to improve the lockfile's usability?

[aignas]

The transitiveDependencies entry for the transitive bzl file hash in the lock file was changing quite often, so that means that GH would constantly tell that the users need to resolve merge conflicts.

Having this is really useful to understand the impact that a change in the bzlmod extension may yield and it is also a good reminder to push as many things to build-time macros instead of having things in the repository rule BUILD.bazel generation time or extension evaluation time.

At the same time, when rules_rust got introduced as a transitive dependency, because they have the arch/os dependent lock file generation on, then it becomes even more painful to keep things up to date.

In general I think the arch/os dependent lock file flag usage is really painful and we should ask users to try to avoid it as much as possible.