Added DumpMachine() and DumpRegister(), some refactoring

[kuzminrobin]

(Feel free to let me know if you'd like me to break this up into multiple PRs)
Added DumpMachine() and DumpRegister() functions implementation.
Added some README.md files (that I've written for myself, to get a more clear understanding for the future of what to add where, and decided to share those).
Did some refactoring of the code.
Resolves #578.

[kuzminrobin]

Please review while I'm resolving the build breaks

[cgranade]

This is a large PR, so I haven't had the chance to finish reviewing it yet; wanted to give initial feedback on what parts I had looked at so far, though.

[swernli]

I'll have a more full review later, but some of these changes (most notably the ones to the headers in the public folder) are breaking changes, such that I think we should have a more general discussion about which parts of our API boundary have dependencies vs not so we can avoid breaking any consumers.

[kuzminrobin]

Looks like I missed an important information earlier. I didn't know that our QIR code has customers.
I need more info about that. If yo have time, then I would really appreciate if you (or anybody else) could tell me more about how the customers use our QIR code.

[swernli]

Yeah, it has definitely been the case up until now that we have been more free to do refactoring based on no external dependencies on this API, but that seems to be changing quickly. The changes you are making here are well thought out and reasonable from the point of view of a C++ API, and give us important things to consider. At the same time, we also should start considering ease of interop with other languages, in which case it might be worth leaning toward a more C-style API that relies on extern functions and basic types instead of objects. All these API design concerns are things that only recently have started coming up, so I think it will be important to have your experience and knowledge to take into account with that before we settle on a firm approach, so between that and the few partners who are taking a dependency on the API it seems we are due for a larger team discussion about how we want to handle updates to the design of the API.

[kuzminrobin]

I have reverted the breaking changes. Please give another round of review.

[swernli]

Some minor comments for you to consider, but overall changes look good to me (though it does look like there is some ongoing discussion with Chris in a few places).