Don't spend an hour on crates that timeout during the build

Currently if we have a build that hits the 15 minute timeout (e.g. app-db-schema@0.1.2) we will end up spending an hour total attempting to build the release. We do 4 builds total, each with the full timeout available to them:

1. With the crates Cargo.lock:
   a. Generate coverage data
   b. Build docs
2. After deleting the lock:
   a. Generate coverage data
   b. Build docs

It would be better to only generate the coverage data if the build succeeded, so we would only attempt builds 1.b. and 2.b. before deciding it timed out, but that has issues

https://github.com/rust-lang/docs.rs/blob/2e5ef9b6d8f13b527436893a9a5e3e67019d5fb3/src/docbuilder/rustwide_builder.rs#L658-L660

One idea would be to skip the subsequent steps if one fails because of a timeout rather than a build error. It seems unlikely that unlocking the crate will turn a timeout into a successful build, or that rustdoc --show-coverage would somehow be the cause of a timeout rather than it being one of the dependencies.

Start in src/docbuilder/rustwide_builder.rs around lines 658-660 and trace how the four build steps handle timeout versus ordinary build failures. Use the app-db-schema timeout example to understand the failure mode. Done means timeout failures avoid unnecessary later attempts while non-timeout build errors retain their existing behavior.