Support alternative frontends

[euclio]

This PR extracts the ember-specific logic into a rustdoc-ember binary. Alternative frontends may be used by setting the RUSTDOC_FRONTEND environment variable.

I've also updated the README. Does the proposed interface for frontends make sense? I also considered sending data.json through stdin.

Fixes #52.

[steveklabnik]

I am psyched about this! Will probably not get to a review until tomorrow though. Thanks!

[mgattozzi]

@euclio This is great!

[steveklabnik]

thanks a ton, overall this looks great! two inline questions for discussion

[steveklabnik]

yeah, I wonder if maybe streaming over stdin isn't better. I feel like it's a tradeoff; my frontend would need to take that stdin and write it to a file anyway, whereas your implementation currently needs to read the file outputted.

I think I'm going to argue that it should be over stdin, because in that case, it only needs to write a file if it actually needs to write a file, otherwise we've left an extraneous file around. Thoughts?

[euclio]

Yeah, I think stdin makes more sense. Certainly if we want to support streaming output.

[steveklabnik]

what do you think about making this a workspace, with rustdoc-ember as a crate inside of it? This would let us get rid of the build script for the main rustdoc crate, which feels cleaner to me.

[euclio]

I'd prefer a workspace as well, but I don't think it's possible to force all crates be built? I'm trying to avoid the situation where you only build the backend and then the frontend can't be found. Though, this does already happen if you just cargo run --bin rustdoc without cargo build. With a workspace you'll have to remember to cargo build --all instead of just cargo build. If that's acceptable I'm happy to make it into a separate crate.

[steveklabnik]

It is, IMO.

[euclio]

Rebased and ready for review.

[steveklabnik]

Awesome, thank you! So pumped about this.