dynamically check dep-graph write patterns

[nikomatsakis]

NB: Part of the roadmap issue on incremental compilation.

We should monitor the dep-graph reads/writes for various bad patterns that may lead to bugs in the output:

• whenever we see a read from node X, there should never be a subsequent write
  • if X corresponds to a missing key in the map, this requires tracking a "poison set"
  • otherwise we can just forbid a write to an already existing key
  • the push() method should be removed
• reading from the set of keys should probably be considered a read of Krate, and we should refactor tasks to allow that read

I tried this and ran into some problems. It's worth taking another stab. I am marking this as mentor -- I would be happy to work with someone who is interested in pursuing it. This will be a bit of an "exploratory" project, so the best thing would be contact me on IRC (nmatsakis; privmsg me and I'll respond as soon as I see it).

The first steps, however, would be to modify the DepTrackingMap, e.g. to "freeze" a key when get() returns None. I would probably do this tracking only if #[cfg(debug_assertions)] are enabled.

[nikomatsakis]

A previous branch that inserted some tombstones to prevent write-after-read: https://github.com/nikomatsakis/rust/tree/incr-comp-tombstone

[nikomatsakis]

we decided it would be better to just remove the bad methods, see #40614