Make kafka dependency optional for runner-google-cloud-dataflow-java

[Abacn]

Fixes #30297

• if KafkaIO is not used, there is no KafkaIO.Read in the pipeline to run override
• If KafkaIO is used, it should already be declared as an implementation dependency

Though it is generally not recommended to catch Error (NoClassDefFoundError), I find this may be preferrable to reduce the number of staged artifacts, and also no longer mandate io.confluent repository to submit a pipeline on Dataflow runner.

Please add a meaningful description for your change here

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

[Abacn]

R: @kennknowles

[github-actions]

Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control

[kennknowles]

I don't love it, but I don't have a better idea. Probably the best thing is to change the runners more seriously.

It seems like a Read(UnboundedSource) should be applicable to runners that use SDF and runners that don't use SDF, with good performance in both cases. In that case, Dataflow v1 only needs to directly implement Read(UnboundedSource) and ignore the expansion and Dataflow v2 can execute the SDF. This is already what happens, no? But I think there is overhead in v2. But there should not be overhead, since there should actually be opportunity for optimization because UnboundedSource is more restricted.