Migrate tests to use Gazelle's integration test runner

[illicitonion]

Advantages:

• allows us to delete a lot of fragile code re-implementing Gazelle's
  internal workfows.
• Each top level testdata directory is a standalone test target which
  can run in parallel, and is independently cached.
• Stdout, stderr, and exit code are assertable artifacts of these tests.
  This is particularly good because right now we have stderr we probably
  don't expect, and this makes that hard to miss. (We can fix up
  removing that stderr in the future).
• Performs a full resolve, rather than a partial one (which means we
  actually see the generated BUILD files as a user would). Several of
  the changes in this PR are adding dependencies as a result of this.
• No longer uses a fake resolver. We can fake things out with
  # gazelle:resolve directives or with an actual maven_install.json if
  we wish.
• Allows easily passing flags to gazelle.

Drawbacks:

• We can no longer assert on the output of generate, only resolve. I
  think this is probably fine - if we want to assert on detected
  imports, that should be probably be done at a Java unit test level
  anyway.
• Currently each of the test targets takes 30 seconds to complete. This
  is because we wait for the Java server to terminate before the test is
  considered complete, and we don't proactively kill it.
  Reworking Java server lifecycle management #70 and
  Add DoneGeneratingRules language hook bazel-gazelle#1325 will address
  this.

Open questions:

• Which tests do we want to have a maven_install.json for vs use
  # gazelle:resolve for vs just assert there's a stderr log?
• What's the future of resolve_test? I don't think it's super valuable
  as-is, but for now I've just preserved it (and moved some helpers into
  it) - let's have this discussion post-merge.

How to review this change:

• All of the BUILD.want.gen files are deleted.
• BUILD.want.res has been renamed BUILD.out - any content changes here
  are because our test pipeline is more faithful to reality than the old
  one was.
• Look at each of the expectedStderr.txt files and if anything looks
  terribly offensive, we should fix it.

[blorente]

Love to see this code go away.
Added some comments and I think it looks good, but the change is large enough that I think it warrants a second opinion.