WxImplementation.ts is identical but has different inheritance in the variants

mapbox:
_layer init in ctor, depends on layeroptions but also passes frameworkoptions to super

class WxTileSource
  extends WxLayerBaseImplementation
  implements mapboxgl.CustomSourceInterface<any>

where
WxLayerBaseImplementation
  extends FrameworkParentClass
  implements WxLayerBaseAPI

and
FrameworkParentClass is just a class

leaflet:

export class WxTileSource
  extends WxLayerBaseImplementation

where
WxLayerBaseImplementation
  extends FrameworkParentClass
  implements WxLayerBaseAPI

but
class FrameworkParentClass
  extends L.GridLayer

we can't make WxLayerBaseImplementation an interface because it has a large concrete implementation we want to be the default

we probably can't do composition because mapbox replaces methods in the class with its own implementations.

mixing-in FrameworkParentClass and WxLayerBaseImplementation
is hard because we need both sets of ctors to run, so requires ctor tampering??
(at least for the leaflet case)

Can we partially invert the hierarchy? Like so:

WxTileSource extends FrameworkParentClass extends WxLayerBaseImplementation???
(this will break the WxLayerBaseImplementation export in the index but we can rename FrameworkParentClass and get the same effect and maintain the interface?)

This seems viable, try it!? How will it work in the cast of leaflet???
Not possible!!!!!!!!!

>>>>>>>> Can we move the _layer init to the ParentFrameWork class and then mixin? <<<<<<<<
>>>> Need to test that it still works work mapbox fn replacement! (but probably should because that happens afterwards!)


N.B. WxLayer export is now type only, this is technically a breaking change


===============================================================
wxsourcetypes contains "interfaces" that are impl specific
wxsource.ts contains differing concepts of WxTile/TileEl (absent in mbox)
            rasterdata/tileel used for updates, might be able to be hidden behind opaque type or interface (raster data impl type only needed for these)
            contains WxTileSource class that probably has a common interface but different extensions
            loadTile/createTile are probably the same concept with diverged naming
            frameworkOptions imported from source to pass to super ctor, can hide behind opaque type?


WxLayerOptions and WxDataSetManager are circular? do we need to fix this?
fix by making createsourcelayer procedural? but is public interface???
frameworkoptions only use for the same

WxLayerOptions should be typed over manager? (but maybe can just use interface)

WxDataSetManager -> WxDataSetManagerI and WxDataSetManager
use interface in common code?


FrameworkOptions should have been a dependent type???


WxDataSetManager.ts is identical across impls, just has dependent imports
WxLayerOptions - circular
WxAPI - use generic type? (or maybe common interface in the future?)

wxapitypes: imports layeroptions and exports a derivative
WxDataSetManagerOptions - depends on API type

wxAPI is basically the same??? except for one section???

start by extracting layeroptions/frameworkoptions/manageroptions???

note that generics are contagious - all the imported usages will need to use them

loader.ts and painter.ts are semantically identical barring comments/var names
but somewhat dependent, loadertools.ts too

TODO FIXME: WxTileSource ctor uses layeroptions which gets weird when that is generic, because we can't do dependent type reference to extended/parent generic templatez

-----------------------

customlayer: mbox has impl, leaflet has dummy
wxsource: impl specific

wxsource uses dsetmanager for typing [lots of common code?]
wxlayer uses dsetmanager for reference and typing [ common code?]
painter, loader, loadertools, and maybe even impl are mostly common?

dsetmanager uses source for injecting itself into creating a source
(stupid)
:: could have a common base class, extend it in each variant to add the injection method and maintain the interface?


alldatasetsmanager looks common?

multilayermanager: mbox specific? why?
wxapi: some code might be common

TODO try make a minimal reproduction of the ?circular module? problem