fix client error when the target is missing (e.g. it's in a comment)

[Fil]

Works by taking the cell out of the dataflow: it won't react to its inputs anymore, won't run, and won't register files and databases.

For an example imagine that at the bottom of docs/lib/d3.md you have the following nasty code with side effects:

${(console.warn("ahahah"), svg.remove())}

If you comment it out, you probably don't want the chart to be removed, nor the warning to appear on the console:

<!--
${(console.warn("ahahah"), svg.remove())}
-->

What this PR does not do is what happens server-side: i.e. if the comment registers a FileAttachment, the file will still be built. Could be a future enhancement?

closes #375

[cinxmo]

What this PR does not do is what happens server-side: i.e. if the comment registers a FileAttachment, the file will still be built. Could be a future enhancement?

Is the file still built? I don't see a network call:

```js
import {FileAttachment} from "npm:@observablehq/stdlib";
```
<!-- <div>${await FileAttachment("gistemp.csv").csv({typed: true})}</div> -->

[Fil]

It's not requested by the page, but I think it's still saved to dist/_file/ by the build script?

[mbostock]

I think it might be better to change how we parse, so that a commented-out inline expression isn’t evaluated at all, i.e., it’s treated as part of the comment text rather than running. Feels related to the other parsing weaknesses we’ve seen #396 #32 #11. On the other hand the solution here is simple and practical, so could be worth including. 🤔

[Fil]

I didn't find how to do this by parsing, but I'm not too familiar with the parser.

[mbostock]

Yes, I think we will probably need a major overhaul of the parser rather than our current approach.

[Fil]

superseded by #597