WMS, WMTS Loaders: Allow for construction based on both literals

[gkjohnson]

Both WMS and WMTS use "capabilities" xml files that parse the file and contain a lot of relevant information for construction and setup. But these XML files seem to be potentially a bit slow to load (perhaps it depends on the service?) and they make the code asynchronous so it would be valuable to be able set up both overlays with string / number literals as well as being able to use the parsed capabilities for convenience.

Currently WMTS requires capabilities and WMS (from #1302) only allows for creation via literals. The strategies should be harmonized - perhaps "capabilities" shouldn't be passed into the constructor but it can just be used to more conveniently create the option arguments.

One potentially difficult point is that WMTS "tile matrix sets" are required as-parsed because the layers are not necessarily reliably structured in a way that allows for generation. It's worth checking what other implementations do.

edit: we should also avoid pre-transforming the CRS values in the capability loaders and instead transform them in the plugins so users can pass in valid values from the formats.

[gkjohnson]

Related to https://github.com/NASA-AMMOS/3DTilesRendererJS/issues/943#issuecomment-3435625747

It would be best to remove any possible dependency on the "capabilities" object or data shapes from XML loaders since the best way for users to use these plugins would be to pass literal values into plugin and skip the (sometimes very large and long to load) processing the capabilities files.

Target option object shapes:

WMTSImageSource

{
  url: string,
  bounds: Array[4],
  crs: string,
  tileMatrices: [ {
    tileWidth: number,
    tileHeight: number,
    matrixWidth: number,
    matrixHeight: number,
    bounds: Array[4]
  }, ... ],
  dimensions: { [key]: any },
  style: string | null,
}

WMSImageSource

{
  url: string,
  layer: string,
  styles: string,
  bounds: Array[4],
  crs: string,
  version = '1.3.0': string,
  format='image/png': string,
  transparent=false: boolean,
  levels=18: number,
  tileDimension=256: number,
}

The capabilities loader results could be cleaned up, as well, to make instantiation more simple. These changes may be a bit significant so it's likely this will have to be a breaking change on a new release.

TODO

• Look at the output from other WMTS and WMS loaders to see if we can align as much as possible and allow for interoperation.
• Look at options required by other mapping engines for WMS and WMTS loading to see if we can simplify the arguments. Initializing the "tileMatrices" specifically seems complex to pass as a literal.