grpc-java only got MODULE.bazel support as of this most recent version:

- grpc/grpc-java#11046
- bazelbuild/bazel-central-registry#1699

This grpc-java version bump exposed two issues that are fixed in this
commit:

1. The //java/com/engflow/notificationqueue:client target dependency on
   @maven//:io_netty_netty_handler broke.

   The original WORKSPACE import of io_grpc_grpc_java imported this
   dependency directly by passing IO_GRPC_GRPC_JAVA_ARTIFACTS directly
   to `maven_install`. The `maven.install` call from grpc/grpc-java's
   MODULE.bazel sets `strict_visibility = True`. Somehow the other
   dependencies registered by grpc-java's MODULE.bazel
   are accessible to notificationqueue:client, but netty-handler isn't.

   The solution was to add the `io.netty:netty-handler:4.1.100.Final`
   artifact to the `maven.install` call in this project's MODULE.bazel.
   It doesn't seem an optimal solution, but it works for now.

2. grpc/grpc-java removed `io.grpc.stub.MetadataUtils.attachHeaders()`
   in grpc/grpc-java#10443.

   This caused notificationqueue:client to fail to compile, but that PR
   revealed the replacement for the deprecated `attachHeaders` call.
   This commit applies that replacement.

This appears to be a fairly recent development, and isn't yet 100%
officially supported in the googleapis/googleapis repo, but it works:

- googleapis/googleapis#855
- bazelbuild/bazel-central-registry#1699

* Enable bzlmod, update README, fix Swift build

Rather than mess with the WORKSPACE rules, the shortest path to fixing
`blaze build //swift:tests` appeared to be introducing MODULE.bazel.

MODULE.bazel, a.k.a. bzlmod, appears to be the new hotness, so I'll also
try updating the other builds to use it as well.

- https://bazel.build/external/migration
- https://bazel.build/external/overview#workspace-shortcomings
- bazelbuild/bazel#18958

* Convert `bazel build //python/...` to MODULE.bazel

* Convert `bazel build //csharp/...` to MODULE.bazel

* Convert //go/..., gazelle to MODULE.bazel

* Migrate protobuf, rules_proto to MODULE.bazel

Also bumps to:

- protobuf: 23.1
- rules_proto: 6.0.0-rc2

* Add rules_java, rules_jvm_external to MODULE.bazel

rules_java was an implicit dependency before.

Bumps:

- rules_java: 7.4.0 => 7.5.0.
- rules_jvm_external: 4.4.2 => 6.0

The rules_jvm_external docs describe using `maven.install` in
MODULE.bazel as a replacement for `maven_install` in WORKSPACE:

- https://github.com/bazelbuild/rules_jvm_external/blob/master/docs/bzlmod.md

However, our current `maven_install` depends on the definition of
IO_GRPC_GRPC_JAVA_ARTIFACTS from @io_grpc_grpc_java. I'll attempt that
migration next.

* MODULE.bazel: skylib, rules_proto_grpc, protobuf

`bazel build //java/...` and `bazel test //java/...` both work with
these changes.

* Move grpc-java to MODULE.bazel, bump to 1.62.2

grpc-java only got MODULE.bazel support as of this most recent version:

- grpc/grpc-java#11046
- bazelbuild/bazel-central-registry#1699

This grpc-java version bump exposed two issues that are fixed in this
commit:

1. The //java/com/engflow/notificationqueue:client target dependency on
   @maven//:io_netty_netty_handler broke.

   The original WORKSPACE import of io_grpc_grpc_java imported this
   dependency directly by passing IO_GRPC_GRPC_JAVA_ARTIFACTS directly
   to `maven_install`. The `maven.install` call from grpc/grpc-java's
   MODULE.bazel sets `strict_visibility = True`. Somehow the other
   dependencies registered by grpc-java's MODULE.bazel
   are accessible to notificationqueue:client, but netty-handler isn't.

   The solution was to add the `io.netty:netty-handler:4.1.100.Final`
   artifact to the `maven.install` call in this project's MODULE.bazel.
   It doesn't seem an optimal solution, but it works for now.

2. grpc/grpc-java removed `io.grpc.stub.MetadataUtils.attachHeaders()`
   in grpc/grpc-java#10443.

   This caused notificationqueue:client to fail to compile, but that PR
   revealed the replacement for the deprecated `attachHeaders` call.
   This commit applies that replacement.

* Move googleapis to MODULE.bazel

This appears to be a fairly recent development, and isn't yet 100%
officially supported in the googleapis/googleapis repo, but it works:

- googleapis/googleapis#855
- bazelbuild/bazel-central-registry#1699

* Move rules_kotlin to MODULE.bazel, bump to v1.9.5

* Move rules_perl to MODULE.bazel, bump to 0.2.0

There's actually a 0.2.1 release, but it hasn't been pushed to
https://registry.bazel.build/ yet.

* Add rules_scala GitHub issue links

rules_scala hasn't migrated to bzlmod yet, but discussion is underway.
These links will help track its progress.

* Migrate aspect_rules_ts to MODULE.bazel

* Replace deps.bzl with go_deps

This enables `bazel {build,test} //infra/...` to succeed using
MODULE.bazel. See:

- https://github.com/bazelbuild/rules_go/blob/master/docs/go/core/bzlmod.md#specifying-external-dependencies

* Set test sizes to "small" as appropriate

This eliminates warnings that these tests are sized too big, since the
default is "medium".

* Move http_{file,archive} calls to MODULE.bazel

This moves the following http_file calls:

- emacs
- ubuntu_20.04_1.3GB

and the following http_archive calls:

- com_engflow_engflowapis
- io_abseil_py

* Update //platform rules, remove dotnet constraints

The //dotnet/toolchain constraint was causing a Bazel error saying that
the @@rules_dotnet//dontent/toolchain package didn't exist. Removing
this constraint allowed remote execution to succeed anyway.

* Update README, explain swift incompatibility

Most of these changes are cosmetic, with the notable exception of the
explantion behind the inability to build //swift remotely.

Also added a `git` command to ignore python/requirements_lock.txt per:

- https://stackoverflow.com/a/73720550

These are in the same PR since they have a circular dependency on each
other

Fixes: bazelbuild#353
Fixes: bazelbuild#1113