Emulator library crate

[jeremyBanks]

Let's break the emulator logic itself, separate from its interface or any binary targets, into a separate crate. We'll keep this in the same repository, and won't publish anything yet, but we'll use a path dependency and call it zerodmg-emulator.

Any generic logic we need to share between both can be grouped into a zerodmg-utils crate, though the ideal would be to move anything substantial into an appropriate standalone package.

For now, the root zerodmg crate will remain the only one with a binary target. Even if we end up having multiple distinct interfaces (perhaps web vs headless CLI), we may still want to keep the single binary target and entry point, with flags to show what we want to invoke.

[jeremyBanks]

I can't publish the parent crate unless the children have real names and versions. I don't want anybody to really use this yet, but I do want to play with the packaging system, so I'll specify a wildcard version for the children.

[dependencies]
zerodmg-emulator = { version: "*", path: "0dmg-emulator" } 
zerodmg-util = { version: "*", path: "0dmg-util" } 

This is awful for consumers, but it should at least let them install and run the latest version, assuming I publish the dependencies at the same time. If I want to run an old version of the code, I'll use this repository, not published version info.

[jeremyBanks]

Perhaps slightly better: use <1 or 0.* to make explicit that we're depending on non-stable versions.

[jeremyBanks]

This seemed nice and clean, but as I was finishing I hit a compiler panic. The endearing error message asked me to file an issue, so I did: rust-lang/rust#51798,

I expect there is a problem in my code, and the compiler is just failing to give me a nice error, not failing on code it should compile.

[jeremyBanks]

unbroken and done in 976629e