… {}` work properly

Before this commit, access to version catalogs from `buildscript {}` and `plugins {}` was working by accident.

The version catalog extensions were added as "provided properties" to the kts script templates for compilation.
There is no IDE editor support for this. When editing such a script the IDE showed red squiggles under the catalog access.
It still found references because of the project extensions for version catalogs but their access was forbidden due to
`PluginDependenciesSpecScope` having `@DslMarker`.

After this commit, new accessors for version catalogs are generated to be available in `buildscript {}` and `plugins {}` and
provided to the IDE. The old way using "provided properties" has been removed.

Generated accessors expose the already existing project extensions for version catalogs. This is done by having
`ScriptHandlerScope` (for `buildscript {}`) and `PluginDependenciesSpecScope` (for `plugins {}`) have an internal protocol
that exposes access to the script target's version catalog extensions. This required moving the internal
`ExternaModuleDependencyFactory` interface from `:dependency-management` up into `:core`.

A new instruction was added to the `ResidualProgram` in kts script compilation to represent `buildscript {}` is a top-level
script that targets `Project`.

Version catalog accessors generation was coupled with plugin spec builders generation as they have the same scope.
Once the `buildSrc` classloader scope is closed, it contains existing Java accessors to version catalogs and the version
catalog extensions have already been added to the project instances.

The `PartialEvaluator` was enhanced to distinguish `buildscript {}` blocks for `Project` in top-level projects where
the version catalog accessors need to be available.

Standaline KTS script compilation already generates plugin spec builders always so no more complexity was added to the
`Interpreter`. If we consider computing these accessors only when necessary we can add the complexity of decoupling
version catalog accessors generation from plugin spec builders generation.

Now that it encompass both version catalog accessors (available in
both `buildscript` and `plugins` blocks) and plugin spec builders
accessors available in `plugins` blocks.

Also reorganize the Stage1BlocksAccessorClassPath.kt file to group
members by responsibility

moving version catalog accessors generation to its own file
moving plugin spec accessors generation to its own file
keeping common code in the Stage1BlocksAccessorClassPath.kt file

It was either `scriptDefinition` or `scriptDef` in the file.
This commit make all such variables named `scriptDefinition` in this file.
For readability.

…m kts plugins block

This is not expected but currently works.

by moving repeated comment to the top
and indenting settings script source in each test

by fixing some formating
by making a method static
by fixing some variable names

… plugins blocks

Doing this required generating new factory classes for version catalogs to hold the
`@Deprecated` annotations and emit the actual deprecation warning.

The classpath used to compile and load the generated code for version catalogs was
amended with the :logging module in order to be able to use the DeprecationLogger.

The new generated classes are produced alongside the regular version catalog factories,
in the same unit-of-work with the same build-cache key. They are also classloaded the
same way with the same build-tree scope caching mechanism.

The version catalog factory instances for plugins blocks have the same lifecycle as the
regular ones registered as project extensions.