optimize dep queue by recording and using crate build times

Describe the problem you are trying to solve
There are a couple of things in the dep queue that could be improved.
Sometimes we and up waiting on a single dep where things could run partly in parallel if the dep queue was ordered differently.

Describe the solution you'd like
If we knew how long a crate usually takes to build on the build host, we could estimates of how long parts of the dep graph take to build and make better decisions on what parts of the tree to start building first, or if it pays out to delay a package artificially in order to build it at a later stage to improve parallelism.

Perhaps we could save build times, compiler version used, build flags, crate metadata etc for each crate and save the data to a file inside the $CARGO_HOME and later read it to improve ordering of the dep queue.

Notes
We probably need to make sure that the files does not grow too much and prune old entries from the crate-build-time database from time to time.

Start by tracing Cargo's dependency-queue scheduling and its existing $CARGO_HOME metadata handling. Define how crate build times, compiler version, build flags, and crate metadata would be recorded, bounded, pruned, and used to reorder the dependency graph. Done means the design and implementation improve parallel scheduling without unbounded database growth.