Extract RcDom into its own crate with no support guarantees

[jdm]

The RcDom implementation was never intended as anything more than a test-only implementation. This work extracts it into a separate crate that contains a README that lays out what sort of support and maintenance guarantees anybody choosing to rely on it can expect (read: none).

Fixes #385.

[jdm]

The first two commits are #384 and can be ignored.

[jdm]

We can choose to either publish the markup5ever_rcdom crate or not.
Benefits of publishing:

• makes the html5ever/xml5ever upgrade easier for anybody relying on the library; they just need to add a new dependency and change a couple imports

Downsides of publishing:

• Much easier for people to cargo-cult the dependency from other projects that depend on html5ever and be unaware of the risks associated with using it

Benefits of not publishing:

• forces any users of html5ever to take on the maintenance of some DOM implementation, presumably by forking the existing rcdom code into their own project
• possibly causes someone else to create the one true html5ever DOM crate

Downsides of not publishing:

• user frustration/confusion when upgrading to new html5ever or trying to use the library for the first time
• high chance of lots of forked copies of rcdom, making it harder for the ecosystem to deal with new security vulnerabilities that are discovered in the future

[nox]

I'm in favour of just killing it and directing people to Simon's Kuchiki crate.

[jdm]

Rebased!

[nox]

@bors-servo r+

[bors-servo]

📌 Commit 9b90752 has been approved by nox

[bors-servo]

⌛ Testing commit 9b90752 with merge 040a4dd...

[bors-servo]

☀️ Test successful - checks-travis
Approved by: nox
Pushing 040a4dd to master...