Sandcastle - Nested gallery structure

[jjspace]

Description

Major changes/focus for this PR:

• All sandcastle JS code is now treated as a single JS module that should import Cesium and Sandcastle directly
  • if the import statements are not in the sandcastle code they will be added before loaded into the bucket. AFAICT this should account for all existing sandcastles that relied on the global objects
  • This also means these objects are not in global window scope anymore
  • Most of the "boilerplate" that previously existed was to set up the window.startup function specifically to account for modules loading out of order. Switching to type=module eliminates that
  • The types importing for Monaco was updated so that it should support intellisense for Cesium and Sandcastle regardless of the imports
• New structure for the gallery which splits the code into dedicated files and relies on a new "metadata sidecar yaml" file for info about a sandcastle
  • index.html is the html/css code for a sandcastle, main.js is the JS code for a sandcastle, sandcastle.yaml holds the metadata and is what dictates that a subfolder is even a gallery example in the first place
  • Note that index.html does not contain the full page structure with head and body tags. This means you can no longer load gallery items directly with a path like localhost:8080/Apps/Sandcastle/gallery/3D Models.html.
    • ^{we feel this was not utilized much and restricted the format too much, maybe we can revisit a way to load them outside of the full SC app in the future}
  • a new script called buildGallery.js has been created to parse through the new gallery structure and generate a top level list.json file. This also does a little basic validation. Where this script lives and exactly what it does is still a little up in the air

TODO:

• Clean up the gallery build script if we're satisfied with the organization structure
  • create a "conversion script" to transform all our existing gallery examples
• Fix loading from a url id
  • Currently the app does not work in a very "react style" and uses a lot of imperative code which is massively conflicting with load order. This is my next focus as a dedicated restructuring pass. after that I think loading will be a lot easier to implement
• Decide on gallery location
  • I think the gallery could live outside of the sandcastle project if we wanted. Given recent comments around the desire to be able to point at any gallery directory I built the logic to hopefully be able to point to any directory from the client. More thought still required but it's in my mind.

Issue number and link

Part of #12566

Testing plan

• run node buildGallery.js to generate the list file
  • need to figure out how to incorporate this into the build nicer
• Load sandcastle both with npm run dev and from the normal server npm start after npm run build
• Make sure the gallery still loads and clicking them loads the examples
  • may want to consider better where these files live for access from both locations and when deployed
• Make sure types in monaco still show up, with and without the import statements
• Copy in the sandcastle code from another sandcastle and make sure it still works

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @jjspace!

✅ We can confirm we have a CLA on file for you.

[jjspace]

@ggetz I tried to split the commits a little between the new gallery files and actual code changes if that makes it easier to review

[jjspace]

Going with the globby approach here instead of just listing the directories lets us "anchor" the existence of a Gallery example around a sandcastle.yaml file.

[jjspace]

Adding the thumbnail property here lets it be named anything. We had discussed maybe not including this and consistently requiring a thumbnail.png or something the same as I am for index.html and main.js. Not sure which approach is better here.
The value is optional regardless if we check for a file or it's defined here.

[jjspace]

I think that doing something like this would allow us to point it at literally any path as long as it conforms to the structure we'd expect. Namely that there's a list.json at the root and [slug]/(index.html|main.js) files. This could help us swap out where it points for different local/deployed builds or even potentially a different server entirely if someone wants to host their own gallery?

[jjspace]

@ggetz I know there's still some scattered commented code and console logs. I'll do a cleanup pass on those before this gets merged but wanted to just validate the approach first.