Minimal non-breaking changes to support nix-ninja

[hinshun]

Hi @evmar, this is a follow up from: #138 (comment)

We have since open sourced https://github.com/pdtpartners/nix-ninja which depends on n2, but I landed on a number of small changes necessary to get it working. I've broken it down to logical commits but I'm also happy to break it up as separate PRs to discuss them individually.

High-level:

• Need several modules to be public
• Need to access the value of dep but it's dropped when initializing the parse_showincludes field
• Need to share Build ins and outs with threads so wanted that to be easily Cloneable
• Want to iterate over DenseMap more generally instead of just GraphFiles

[evmar]

This seems mostly fine. I am still worried some n2 change I make in the future will break you but I also don't expect to tinker with it much in the future.

(You should be also aware that n2 doesn't implement all of ninja's semantics, which means for some projects it will build wrong...)

[evmar]

Given this should only ever be "gcc" or "msvc", I think this should at least be an enum. (I don't really understand why you need this, it seems the bool carried as much info as before?)

[hinshun]

I was thinking of keeping it open as an extension point, e.g. for python dependency inference, etc. Is this the wrong use of the deps field?

[evmar]

It maybe is, but even if we ever added some new mechanism, adding it to an enum is reasonable too.

[hinshun]

This seems mostly fine. I am still worried some n2 change I make in the future will break you but I also don't expect to tinker with it much in the future.

That is fine, we will handle the updates / breakages.

(You should be also aware that n2 doesn't implement all of ninja's semantics, which means for some projects it will build wrong...)

I understand, this is good enough as a starting point.