fix(ci): vendor deno for builds

[rwaskiewicz]

Why is CI failing?

Stencil has experimental support for Deno, and as such needs its dependencies during the build process. Similar to running npm ci, we would pull our dependencies from Deno. Something has changed, although I can't pinpoint it well, where we can't pull the deps we need reliably.

What does this PR do?

This PR takes a 'fresh enough' cache of our Deno dependencies, and vendors them under scripts/build/deno-deps. I say 'fresh enough' because it's hard to reliably pull these dependencies locally if one were to bust their cache, so I'm using my 'best known' version of things here.

Commit Message

add deno source files (vendor them) for more reproducible builds. these
files are being committed to the repo to help stabilize the CI process,
which as been failing for 24 hours.

the stencil team still considers deno to be experimental, this commit
does not mean to imply further development on deno support

FAQ

Is vendoring these a bad idea?

I'd argue no. Although running npm install or npm ci with NPM/node and relying on package-lock.json to create reproducible builds, Deno does not take this approach. The suggestion for production builds is to do something very close to what I have here

Why aren't we using deno cache? Wouldn't that be a better alternative?

It probably would be better to use deno cache. I did attempt this by running DENO_DIR=./src/sys/deno/deno-deps deno cache --unstable src/sys/deno/deps.ts, which effectively downloads those dependencies for you. I was able to download those files successfully. BUT! This had two issues:

1. The files downloaded are slew of JSON files and hash-named TS files, and I can't figure out how to get them to resolve properly (or if any work is really needed to do that, if it's Deno-magic or not).
2. Stencil assumes that a Deno source file, resolved by an identifier (the importee used in a file) can be transformed by us. So there's a bunch of tweaking I'd have to do to the deno-std-plugin at the very least to transpile things. This short circuits the process for now

What Risk are we Assuming?

That we could break existing Deno users, although I don't think there's conclusive evidence Deno support really works ATM

This PR also assumes that my fresh enough cache is fresh. If someone wants to double check, we could have them copy their scripts/build/deno-cache off to the side, then pull this branch, then replace what I have here. Any diff could/should be discussed. FWIW, I did a diff of two stencil directories I had, and didn't see any diffs

What should follow this PR?

1. an ADR for this decision
2. an RFC issue in the Stencil repo about removing Deno

[splitinfinities]

These changes make sense. Great PR description as well.