Refactoring of the approach to construction Geometry engine

[andyward]

Aim here is to support building an XbimGeometryEngine with both DI , as well as traditional constructor approaches.

Generally cleaned up the construction and config approach and fixed up issues arising from use of a static . We now use an internal DI IServiceProvider when one is not used externally.

Introduced a configurable approach for constructing a geometry Engine.

Without CI:

var engine = new XbimGeometryEngine(model, loggerFactory, 
    new GeometryEngineOptions {GeometryEngineVersion=XGeometryEngineVersion.V6});

with DI:

// In Startup
var services = new ServiceCollection();
services.AddGeometryServices(opt => opt.Configure(o => o.GeometryEngineVersion = XGeometryEngineVersion.V6));

// ... then either inject the IXbimGeometryEngine in a ctor, or get from serviceProvider
var engine = servicesProvider.GetRequiredService<IXbimGeometryEngine>();

// Register the current model, which associates a new native Geometry Engine
engine.RegisterModel(model)

TODO:

• [x] move the IGeometryRegistration interface into IXbimGeometryEngine. DONE

Note: the Assembly Resolver approach is not needed for Geometry as we load the native DLL explicitly, and is no longer registered. But the class remains in case we need to reintroduce due to unforseen sideeffects (as this was a global resolver)

[andyward]

Remaining work is to integrate with https://github.com/xBimTeam/XbimEssentials/pull/483 - removing static Logger and introducing common ServiceProvider for xbim (which can replace the Xbim.Geometry.Engine.Interop/Internal/XbimGeometryInternalServices.cs)