As part of #1142, we want to reduce the transitive dependencies of
oapi-codegen.

We can start by breaking some dependencies between packages that don't
make sense.

As part of #1142, we want to reduce the transitive dependencies of
oapi-codegen, which we can start with by removing unnecessary
dependencies on `echo` from the `pkg/codegen` project.

As part of #1142, we want to reduce the transitive dependencies of
oapi-codegen, which requires creating a multi-module Go project.

Before we can do this, we can make sure that we have set up our Makefile
and `tidy` workflow to be module-aware via steps in [0].

[0]: https://www.jvt.me/posts/2023/08/18/go-multi-module-execute/

As part of #1142, we want to reduce the transitive dependencies of
oapi-codegen, which requires creating a multi-module Go project.

We can start with the `examples` project, which definitely shouldn't be
pulled by consumers.

The fake module version updates across all files due to the way that
multi-module Go projects work, but should be a one-time update.

As part of #1142, we want to reduce the transitive dependencies of
oapi-codegen, which requires creating a multi-module Go project.

We can migrate `internal/test` to its own module, as it shouldn't be
(nor could it be) pulled by consumers.

The fake module version updates across all files due to the way that
multi-module Go projects work, but should be a one-time update.

As part of #1142 we can start to reduce our transitive dependencies
by refactoring the `pkg/runtime` as it exists in
deepmap/oapi-codegen.

This allows us to introduce a breaking change (tweaking the structure of
this package, including moving the `strictmiddleware` concepts) by
creating a fresh package. This does require we tweak the way that our
imports and generated code works.

By moving `runtime` to a separate package, we can allow more frequent
updates to the runtime-specific code, without tying it directly to the
version of the code generator in use.

As we're now using the oapi-codegen/runtime package for this, we should
mark the existing functionality as deprecated.

This also ignores any internally flagged deprecation warnings, as we
know we're calling deprecated functions from within our own (deprecated)
packages.