feat: support multiple document yaml files

[crandles]

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:

example

{
    "/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.:

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: crandles
Once this PR has been reviewed and has the lgtm label, please assign alexzielenski for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment