`alloy.openapi` namespace in alloy conflicts with the one in smithy4s-core

This is new - caused by a recent addition of alloy.openapi to allowed namespaces in core, in https://github.com/disneystreaming/smithy4s/pull/1822.

The problem appears when you have alloy-openapi and smithy4s-core on the same classpath. I can see two reasons why this might happen:

• you're generating openapis programmatically in a Scala application at runtime, and the application is using smithy4s-core in one way or another
• you're using smithy4s-core in your build, and the same build is also using the smithy4s-codegen plugin (which involves alloy-openapi).

Depending on the ordering of jars on the classpath, you may get this at runtime: NoSuchMethodError on one of the alloy.openapi methods - because smithy4s-core shows up on the classpath first and the generated alloy.openapi.package package object class gets loaded from that jar.

To reproduce:

touch input.smithy
cs launch com.disneystreaming.smithy4s:smithy4s-codegen-cli_2.13:0.18.43 com.disneystreaming.smithy4s:smithy4s-core_2.13:0.18.43 -- generate ./*.smithy

java.lang.NoSuchMethodError: 'scala.collection.immutable.List alloy.openapi.package$.convertWithConfig(software.amazon.smithy.model.Model, scala.Option, scala.Function1, java.lang.ClassLoader)'
	at smithy4s.codegen.internals.CodegenImpl$.generate(CodegenImpl.scala:96)
	at smithy4s.codegen.Codegen$.generate(Codegen.scala:22)
	at smithy4s.codegen.Codegen$.generateToDisk(Codegen.scala:25)
	at smithy4s.codegen.cli.Main$.$anonfun$main$1(Main.scala:46)
	at smithy4s.codegen.cli.Main$.$anonfun$main$1$adapted(Main.scala:44)
	at scala.util.Either.map(Either.scala:390)
	at smithy4s.codegen.cli.Main$.main(Main.scala:44)
	at smithy4s.codegen.cli.Main.main(Main.scala)

Note: in theory, it's possible that some value members will get added to smithy4s-core's alloy.openapi package object, which currently is:

package alloy

package object openapi {

  /** This traits allows the encoding of OpenAPI Extensions
    * as defined in https://swagger.io/docs/specification/openapi-extensions/.
    */
  type OpenapiExtensions = alloy.openapi.OpenapiExtensions.Type
  type Summary = alloy.openapi.Summary.Type

}

and then the opposite order of jars on the classpath will cause NoClassDefFoundError - but that's not possible at the moment.

Current workaround: put the alloy-openapi jar on the classpath first. That should avoid any conflicts for the time being.

Reproduce the failure with the documented cs launch command and empty input.smithy. Start at smithy4s.codegen.internals.CodegenImpl.scala:96, then inspect Codegen.scala and cli.Main.scala alongside the alloy.openapi package object described in the issue. Done means the codegen invocation works when smithy4s-core and alloy-openapi share a classpath without the reported linkage error.