The Node.js buildpack had a set of Bash helper utils for managing a
key-value store of metadata, that could be added to during the build,
and then output when bin/report was run.

When the Python buildpack added support for bin/report, its
implementation was based on the Node.js one, with some further small
improvements.

However, there remains a number of issues with the design:
1. It handles different data types (string vs int vs float vs bool) at
   `bin/report` time, so requires a hardcoded mapping of values which
   can (and does) get out of sync. (Plus doesn't work well for some
   cases, like jvm-common being wrapped by the other JVM related
   buildpacks.)
2. It tries to escape newlines and carriage returns, but there are a
   number of edge cases still not handled properly which result in some
   fields not being sent to Honeycomb properly.

In order to work around the above, Manuel created a jq based approach
for use by the JVM buildpacks:
https://github.com/heroku/heroku-buildpack-jvm-common/blob/4fd6e4f8f258a5766a8b2e9ffec2690675b00879/lib/metrics.sh

However, that doesn't have the full API of the existing solution (it's
missing the ability to fetch previous values; something which Python
needs), and I spotted a few more places where things can be optimised.

In addition, now that we're using jq and JSON internally in the
buildpack, it makes sense for us to update cytokine to support the
build report being emitted as JSON too (in addition to YAML),
particularly since cytokine then submits the report to Vacuole as
JSON afterwards.

And in fact, since JSON is roughly a subset of YAML (at least for the
simple data types and schema we're using for the build report), we can
start emitting the build report as JSON now, rather than needing to wait
for the cytokine change to land first. (We'll still want to update
cytokine to use a JSON parser though, just to avoid any edge cases in
the future).

The new implementation:
- Sets the data type at the call site where the metadata is set,
  rather than relying on a hardcoded mapping at time of retrieval.
- Uses jq to do the string escaping, so much less fragile than the
  hand-rolled implementation.
- Uses a simplified initialisation/setup API, which avoids the need to
  call both `init` and `setup`.
- Has been rewritten to avoid unnecessary processes calls, redirections,
  and patterns that required disabling a number of shellcheck warnings.

I've confirmed that metrics still appear in Honeycomb with the changes
here.

After this merges, I'll open PRs against some of the other language
buildpacks that don't yet implement `bin/report`, using the improved
implementation from here (with simplifications since other buildpacks
won't need the legacy data store handling that Python needs to support
caches written by older buildpack versions).

GUS-W-19344754.

Co-authored-by: Richard Schneeman <richard.schneeman+foo@gmail.com>
Signed-off-by: Ed Morley <501702+edmorley@users.noreply.github.com>