release Compiler v1.12.0 (and discussion on how to use it)

For external packages like Cthulhu that use the Compiler.jl stdlib, it's
quite a hassle to manage all three types of compatibility: between the
external package, the Julia runtime, and Compiler.jl.

I'm thinking instead of handling these compatibility issues by some
complex version engineering for Compiler.jl, we should keep its use
supplementary. External `AbstractInterpreter` packages should primarily
use `Base.Compiler`, while managing compatibility with the Julia runtime
and `Base.Compiler`. This would bring us back to the previous situation,
but it seems better in terms of compatibility management.

On the other hand, using the Compiler.jl stdlib allows for easy
switching of the `Compiler` implementation, which should be an optional
benefit. This is especially useful when developing the `Compiler`
itself, where it's common to do `pkg> dev /path/to/Compiler`. In such
cases, the implementation of the Compiler.jl stdlib should be used
instead of `Base.Compiler`.
As a mechanism to switch the `Compiler` implementation used by external
`AbstractInterpreter` packages, using package extensions might be the
simplest approach. As shown in
[this example PR](JuliaDebug/Cthulhu.jl#619),
we can switch the `Compiler` implementation when `using Compiler` is
called[^1], and still precompile the usual code. However, to list
Compiler.jl in `[extensions]`, it needs a version. To this end, I
propose releasing Compiler.jl versions in line with the Julia runtime
versions, following other Julia standard libraries. But we would only do
minor version releases, not patch releases, which are harder to define.
Specifically, we could release a corresponding version of Compiler.jl
when a release branch is cut. After that, we wouldn't manage patch
versions, and as long as `pkg> dev /path/to/Compiler` works, this simple
versioning should suffice.
Alternatively, we could register a single version `1.0.0` of Compiler.jl
with a dummy implementation, letting the external package determine if
the implementation is real (developed) or dummy, but this seems more
hacky than using package extensions.

[^1]: Also, I'm aware of another issue: when using the Compiler.jl
  stdlib, you need to run `InteractiveUtils.@activate Compiler` first,
  or else some reflection utilities won't work (for example,
  `Base._which(tt; method_table=Compiler.method_table(myinterp))`).
  I think this problem can be solved by adding
  `InteractiveUtils.@activate` in the `__init__` function of the package
  extension code, but I'm not sure if this is a safe solution. It might
  be better to set up a callback that only gets called when
  `InteractiveUtils.@activate` is executed?

Compiler/Project.toml

@@ -1,9 +1,9 @@
 name = "Compiler"
 uuid = "807dbc54-b67e-4c79-8afb-eafe4df6f2e1"
-version = "0.0.3"
+version = "1.12.0"
 
 [compat]
-julia = "1.10"
+julia = "1.12"
 
 [extras]
 Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"