[ui] Pack metadata booleanified and added to the statuses endpoint

[philrenaud]

Context: Way back in Two-ought-twenty-two, we added a visual indicator for whether a job was run via Nomad Pack in the UI. We could do this because the /jobs endpoint returns job meta information, and pack consistently puts meta.pack.name etc. such that we can detect it.

With the purpose-built /statuses endpoint, we can be choosy about what we want to include and by default weren't delving into job metadata.

This PR checks to see if any of the tell-tale signs of pack are present, and if so, presents an isPack boolean to the endpoint that the UI turns into a little badge:

[philrenaud]

This could very well be too expensive for this endpoint, but I'm a little blind to how much we ought to tolerate here. For example, the possibility of a job with many, many instances of metadata entries gives me pause. If there is a more clear-cut indicator of "this came from pack", I'd love to use that, but I think metadata is the best bet.

[gulducat]

since we know specific pack. meta key(s), instead of iterating the map which could potentially be arbitrarily long, as you mentioned, and getting string processing involved, I think we can do a simple map lookup. also fun tidbit: you can attempt to access a nil map without nil-checking it, so I think all this can boil down to:

	_, isPack := job.Meta["pack.name"]

but also, and this is totally personal taste, I like to do static type definition of what I'm gonna return up top, then populate it with whatever extra processing afterwards. so I'd personally do this down underneath jsj definition somewhere instead:

	_, jsj.IsPack = job.Meta["pack.name"]

[philrenaud]

This is way simpler and setting it unorphaned makes a lot of sense. Updating now!

[github-actions]

Ember Test Audit comparison

	main	4d4a1cb	change
passes	1572	1572	0
failures	0	0	0
flaky	0	0	0
duration	11m 15s 911ms	11m 38s 501ms	+22s 590ms

[tgross]

LGTM!