Merge hive2 and hive3 support into one branch as Gradle subprojects

[popematt]

Issue #, if available:

None

Description of changes:

• Merges hive2 and hive3 support into one GitHub branch as Gradle subprojects
  • This is one way that does work. It might not be the best way. It may be possible to restructure the project a little more simply like in emr-dynamodb-connector. It might also be possible to move the different versions into one subproject with multiple source sets.
• The serde subproject of the hive2 branch has been moved to a hive2 subproject. Similarly for hive3.
• Updates to Gradle 8.5
• Uses the shadowJar plugin instead of having a custom task for building the fat jars.
• Removes the transitive dependency on the Kotlin Standard Library from the fat jars. (It was brought in somehow even though it was used only for test code.)
• Converts most build files to Kotlin. The only files still using groovy are integration-test/build.gradle and the (now trivial) root build script.
• Parts of the build logic that are shared have been extracted into Gradle convention plugins in the buildSrc directory.
• All projects in this repo now have the same version (currently 1.3.0-SNAPSHOT).
• Copyright header was updated to be shorter, SPDX-compatible, and not mention the year 2018.

Limitations:

• Integration tests currently target only the hive2 subproject.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[jobarr-amzn]

How do we feel about wildcard imports? I know in other projects we've leaned away from it, I don't really care one way or another so long as we're consistent.

Personally I have a lot of sympathy for this argument: https://stackoverflow.com/a/149282 .

[popematt]

I know there isn't necessarily consensus about wildcard imports in general, but I think there's absolutely no problem with wildcard imports of other packages that we also maintain.