Use one multi-module gradle build

[larsgrefer]

fixes #1790

• Common gradle configuration should be moved to an subprojects{} block in the root build.gradle
• various scripts need to be updated (build.sh, **/kokoro/*.(sh|bat), etc.)

[chanseokoh]

Thanks for the idea!

We are unsure when we will restructure the repo given the resources we have, but this PR will serve a nice reference when that happens.

[loosebazooka]

@larsgrefer, yeah as @chanseokoh this is great, we might want to do some shading (to include plugins core directly in our plugins jars) and generation of test artifacts so we can include testCompile project(path: "jib-core", configuration: "test-utils") or something.

But before you start going too deep on this, I think we're are actually going to go a little slow on this though as we will need to retool our release process, etc to accommodate.

[larsgrefer]

Sure. This PR is only meant as proof-of-concept.

To make this work some additional changes are necessary:

• The io.freefair.maven-plugin plugin is based on the (new) maven-publish plugin, while the other gradle builds in jib still use the (old) maven plugin.
• The helper scripts (build.sh etc.) need to be revisited.
• The surrounding CI/CD pipelines might need to be adjusted.

Once this is done, the multi-module project opens the way for further simplifications:

• Most of the build configuration can be centralized in the root build.gradle (java versions, checkstyle rules, publishing, java-format, errorprone, etc.)
• The current behaviour of modifiying the source sets of each sub-module can be changed to acutal dependencies. (These could then be shaded again).
  • The test code which is currently shared between the modules should be extracted into a separate jib-test-utils module, which can then be a testCompile dependency of the current modules.

[loosebazooka]

going to go ahead and close this in favor of #1835 thanks for your contributions.