Fallback to CDN imports when libraries needed by FileAttachment are not detected through static analysis

[mbostock]

The FileAttachment methods have implicit imports:

• FileAttachment.dsv, FileAttachment.csv, and FileAttachment.tsv use npm:d3-dsv.
• FileAttachment.arrow uses npm:apache-arrow.
• FileAttachment.parquet uses npm:apache-arrow and npm:parquet-wasm.
• FileAttachment.arquero uses npm:arquero, and maybe npm:apache-arrow and npm:parquet-wasm.
• FileAttachment.sqlite uses observablehq:stdlib/sqlite.
• FileAttachment.zip uses observablehq:stdlib/zip.
• FileAttachment.xlsx uses observablehq:stdlib/xlsx.

Normally we detect these through static analysis, but we can’t guarantee that we always detect which methods are used through static analysis. For example see https://talk.observablehq.com/t/404-errors-in-module-load/9623. A trivial example where static analysis fails is:

const file = FileAttachment("file.csv");
const data = await file.csv();

When static analysis fails, built sites currently break because they try to load the self-hosted copy of the library (which doesn’t exist because we only host copies of libraries that we know are used). Perhaps we should fallback to jsDelivr instead, so at least the site keeps working?

Alternatively, we could add a copy of these libraries even if we don’t detect that they’re used, but I don’t think people will like hosting copies of unused libraries.

Alternatively, we could make the static analysis heuristic more lax, for example looking for file.csv() calls and not just FileAttachment("name.csv").csv() calls, but that could have false positives.

Related #1574.