simplify usages of model catalog.

we know what model catalog we need for a given edition, and we know what point in the plugin lifecycle we need it. so we just get what we need, when we need it. nothing clever.
concretely, the invariant is that all extension entry points run and finish before any lifecycles initialise.
so while we have several extensions needing model catalog, we can illustrate in code the guarantees we know about. specifically, when an extension needs model catalog in it's lifecycle only, then we can just get the already created one; whereas when you need it in extension init itself, you are competing and must do a synchronised singleton get-or-create type thing.
this will be much clearer when we merge the extensions.

Author: lassewesth

edition-api/src/main/java/org/neo4j/gds/EditionLifecycleAdapter.java

@@ -27,7 +27,7 @@
 import org.neo4j.gds.configuration.DefaultsConfiguration;
 import org.neo4j.gds.configuration.LimitsConfiguration;
 import org.neo4j.gds.core.OpenGdsIdMapBehavior;
-import org.neo4j.gds.core.model.OpenModelCatalogProvider;
+import org.neo4j.gds.core.model.OpenModelCatalog;
 import org.neo4j.gds.core.write.NativeExportBuildersProvider;
 import org.neo4j.gds.metrics.Metrics;
 import org.neo4j.gds.procedures.ExporterBuildersProviderService;
@@ -71,7 +71,7 @@ public Lifecycle newInstance(ExtensionContext extensionContext, Dependencies dep
         var featureTogglesRepository = new FeatureTogglesRepository();
         var idMapBehavior = new OpenGdsIdMapBehavior();
         var metrics = Metrics.DISABLED; // no metrics in OpenGDS
-        var modelCatalog = new OpenModelCatalogProvider().get().orElseThrow();
+        var modelCatalog = new OpenModelCatalog();
         var modelRepository = new OpenModelRepository(); // no model storing in OpenGDS
         var poolSizes = new OpenGdsPoolSizes(); // limited to four