Provide thin jar for swagger-codegen

Similar to swagger-api/swagger-parser#1515, #10853, and https://github.com/swagger-api/swagger-codegen/issues/10854, we want to be able to call SwaggerCodegen.main programmatically.

But the swagger-codegen jar is published as an executable jar, because the assumption was that it would be run from a command line.

Because an executable jar (a.k.a. fat jar, a.k.a. shadow jar) has every class needed to execute, it put thousands of classes on our classpath, many of which conflict with other classes (in fact, it made the code generator malfunction until we realized the problem).

For now, we had to fork the classes from the swagger-codegen jar into our codegen project:

src/main/java/io/swagger/codegen/v3/cli/CLIHelper.java

src/main/java/io/swagger/codegen/v3/cli/SwaggerCodegen.java

src/main/java/io/swagger/codegen/v3/cli/cmd/ConfigHelp.java

src/main/java/io/swagger/codegen/v3/cli/cmd/Generate.java

src/main/java/io/swagger/codegen/v3/cli/cmd/Langs.java

src/main/java/io/swagger/codegen/v3/cli/cmd/Meta.java

src/main/java/io/swagger/codegen/v3/cli/cmd/Validate.java

src/main/java/io/swagger/codegen/v3/cli/cmd/ValidateException.java

src/main/java/io/swagger/codegen/v3/cli/cmd/Version.java

We really didn't want to have to fork anything.

We'd like to be able to depend on a thin version of swagger-codegen, which you could enable by publishing two artifacts instead of one, with the thin artifact having a different artifactId.

Review the current executable-jar packaging and the listed CLI classes under src/main/java/io/swagger/codegen/v3/cli. Compare the related issues referenced in the report to understand the intended artifact split. Done means publishing a second artifact with a distinct artifactId that provides the CLI classes without bundling all executable-jar dependencies.