Use settings from .istanbul.yml when configuring instrumenter

[shackpank]

I've just tried this out against a test suite that opens 300+ subprocess during the run and it works great, so thanks!

There was an issue with some tests though, specifically tests covering code that uses the heredoc package would fail when run wrapped by this module. This is because normally, instrumenting a file results in all comments being stripped from it, and heredoc uses a comment-based workaround to enable multi-line strings.

There is an option that can be provided to the istanbul instrumenter to preserve comments - this changes how the instrumenter is initialised, so its options can be read out of a .istanbul.yml file in the project root and passed in.

The other three passed in options I don't actually need, but they match how the instrumenter is initialised by istanbul's own CLI command.

Provided you're OK with the change, guidance on how to test this would be appreciated - I'd normally move the new istanbul.Instrumenter into the NYC constructor, then bring in sinon to stub the return value of loadFile and assert new istanbul.Instrumenter was called with it, but it looks like that may not be inline with this project's style?

[coveralls]

Coverage remained the same at 99.03% when pulling 67a86b2 on shackpank:read_istanbul_config into 891e849 on bcoe:master.

[bcoe]

@shackpank thanks a ton for digging into this. One question, and potential unit test comes to mind, is istanbul.config.loadFile().instrumentation.config smart enough to find the configuration file if our tests are changing cwd, perhaps we should be using process.NYC_CWD (or maybe istanbul is clever).

For testing, I am perfectly fine with you pulling istanbul into the constructor so that you can mock it. When I want to mock something I usually would just switch from istanbul to _this.iistanbul and toss it in the constructor.

[bcoe]

@shackpank see: #16 thanks a ton for the contribution.