The current buildpack-test-runner shunit2 integration tests are not
fully representative of production, slow, and the test runner in need
of maintenance.

Using Hatchet for tests ensures parity with production and means we can
use much greater concurrency (since we can rely on platform capacity).

In the future some tightly scoped bash *unit* tests may also be added
to the buildpack using a more up to date bash testing framework, once
the buildpack's bash scripts have been refactored to be more testable.
However even with these, we'll still want production end to end tests
using Hatchet.

This is the first of several PRs to convert the existing shunit2 tests
to Hatchet, and whilst doing so add missing test coverage.

With these new Hatchet tests, I've decided to start validating the build
log output more strictly (ie: asserting against multiple lines), since:
* the build log is an important part of a buildpack's UX, and something
  I plan on improving over the coming months
* it's the only way to ensure various error lines aren't being output,
  without having to report to fragile negative assertions like these:
  https://github.com/heroku/heroku-buildpack-python/blob/90f3eeadfe5ef4aadd7439e9a646868de7180852/spec/hatchet/python_spec.rb#L14
  (longer term after the buildpack is refactored we can reduce the
  chance of these errors being emitted by enforcing exit on error
  everywhere, but even then we likely want to catch non-fatal warnings
  emitted by tools such as pip or pipenv)

The tests were written following the rspec style guide:
https://rspec.rubystyle.guide/

Note: The newly added Hatchet tests don't yet test post-deployment
functionality since the existing tests didn't either - this will be
added in future PRs.

Closes @W-8665943@.

[skip changelog]