What type of PR is this?

/kind bug

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes #123

Special notes for your reviewer:

• (Option 1) This introduces a breaking change in the output, in the initial draft. Something needs to represent the additional detail.

{
    "/tmp/foo.yaml": [
        [
            { // doc one
                "metadata": {},
                "status": "Success"
            }
        ],
        [
            { // doc two
                "metadata": {},
                "status": "Failure",

• (Option 2) An alternative would be to ensure that the "metadata" of the status object includes the right detail:

{
    "/tmp/foo.yaml": [
            { // doc one
                "kind": "...",
                "apiVersion": "...",
                "name": "...",
                "status": "Success"
                "details": {
                  "name: "..."
                }
            },
            { // doc two
                "kind": "...",
                "apiVersion": "...",
                "name": "...",
                "status": "Failure",
                "details": {
                  "name: "...",
                  // ...
                }

I think the second option might be nicer, I'll follow up with that shortly for comparison.

The above appear to be existing fields in the status we could populate.

On closer look, name is already in use, so that won't work as first thought, nor do I think it would work with generated names well.

• (Option 3) Extend the json "key" to include additional metadata

{
    "/tmp/foo.yaml:$(documentNumber}": [

or

{
    "/tmp/foo.yaml:$(gvk}:$(name}": [

Potentially, we could make it so that the key is returned in the prior format if there is only 1 document in a file?

• (Option 4) Alter the return type: map[string][]metav1.Status{} -> map[string][]NewType{}

As this doesn't break the general structure of the output and simply extends it, I'm inclined to try this out:

{
  "document":0, // document index
  // ... current metava1.Status fields, inline
}

Does this PR introduce a user-facing change?

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: