bring this crate into conformance with compiler-team crate policy

[nikomatsakis]

The compiler team is working on a standard policy around its external crates (see rust-lang/compiler-team#19) -- we need to bring this crate into conformance, though the policy is not yet finalized, so it's not 100% clear what this means.

[Cypher1]

Hey @nikomatsakis looks like rust-lang/compiler-team#19 has been closed a while.

Can you share any requirements from it for this crate?

Context: I'm doing some Rust + Logic programming work at the moment and am trying to find some time to contribute back so am looking for starter issues.

[IFcoltransG]

From the current crate procedure it looks like some steps to take are:

• Specify that the crate is maintained by the Rust compiler team and any appropriate working groups.

  In particular, this should detail the expected level of maintenance and stability for any prospective users.
  This should also link to the working group details in this repository.

• Be added to the list at the bottom of this page (i.e. the document linked above).

• Use @bors and @rust-highfive.

• Use labels that are compatible with the existing triage process. This will allow nominated issues in your out-of-tree crate to be discussed during triage meetings.

  eg. T-compiler, I-nominated (a full list is to be decided)

From the setup process it also says (with example):

• Add a README describing the intended purpose of the crate, which team and working group are responsible (link to their page in this repository) and the intended level of maintenance and stability.

  This crate is developed and maintained by the Rust compiler team for use within rustc, in particular, it is the responsibility of the .template working group. This crate [will have regular breaking changes and provides no stability guarantees|is intended to remain stable and have limited breaking changes].

• Create P-high, P-med, P-low, I-nominated and T-compiler labels.

[Noratrieb]

also see https://rust-lang.github.io/rfcs/3119-rust-crate-ownership.html

note that we do not want to use bors for any new projects. GitHub merge queues should be used instead.