…e, r=alexcrichton

Fix rebuild_sub_package_then_while_package on HFS.

This test was flaky on HFS ([azure failure](https://dev.azure.com/rust-lang/cargo/_build/results?buildId=20144&view=logs&j=a5e52b91-c83f-5429-4a68-c246fc63a4f7&t=d4864165-4be3-5e34-b483-a6b05303aa68&l=2018)), resulting in this error:

```
   Compiling foo v0.0.1 (/Users/runner/runners/2.164.7/work/1/s/target/cit/t750/foo)
error[E0460]: found possibly newer version of crate `b` which `a` depends on
 --> src/lib.rs:1:1
  |
1 | extern crate a; extern crate b; pub fn toplevel() {}
  | ^^^^^^^^^^^^^^^
  |
  = note: perhaps that crate needs to be recompiled?
  = note: the following crate versions were found:
          crate `b`: /Users/runner/runners/2.164.7/work/1/s/target/cit/t750/foo/target/debug/deps/libb-98160c67a5811c37.rlib
          crate `b`: /Users/runner/runners/2.164.7/work/1/s/target/cit/t750/foo/target/debug/deps/libb-98160c67a5811c37.rmeta
          crate `a`: /Users/runner/runners/2.164.7/work/1/s/target/cit/t750/foo/target/debug/deps/liba-7d2b9ccd932a36e9.rmeta
```

There are two race-condition bugs here.

Race 1: The second cargo build command (`cargo build -pb`) would sometimes not build, because it thought `b` is fresh.  This can happen when the first build finishes and changing `b/src/lib.rs` happen within the same second. (#5918)  The test silently ignored this failure, this is not the cause of the CI failure, though.

Race 2: The first and second build commands work as expected.  The third build command fails because it thinks both `a` and `b` are "fresh".  However, `b` was just rebuilt, and `a` depends on it, so `a` should have been rebuilt.  It thinks `a` is fresh because `a`'s mtime is equal to `b` when `b` finishes compiling within the same second that the first build finished.

The solution here is to make sure the second step happens well after the first.  The underlying problem is #5918.