Fix handling of 'has' selectors

[antoineco]

Fixes #467

The first commit includes test cases which surface the issue.

The second one includes a fix, which consists in treating a missing metadata.labels as a {} map.

---

Test run before fix:

--- FAIL: TestMatchesSelector (0.00s)

    --- FAIL: TestMatchesSelector/single_non-labeled_object_with_not-has_selector (0.00s)
        selector_test.go:215: unexpected result: got false - want true

    --- FAIL: TestMatchesSelector/not-has_selector_matching_all_non-labeled_elements_of_list_object (0.00s)
        selector_test.go:200: unexpected result: got false - want true
        selector_test.go:209: unexpected diff (-want, +got)   (
                """
                ... // 3 identical lines
                    resourceVersion: ""
                    selfLink: ""
            -   items:
            -       - apiVersion: v1
            -         kind: Pod
            -         metadata:
            -           name: rss-site
            -       - apiVersion: v1
            -         kind: Pod
            -         metadata:
            -           name: rss-db
            +   items: []
                """
              )

[antoineco]

Notes to reviewers.

[antoineco]

The only case where docKind() returns an empty kind string without error is when the node is a !!null node.

I'm not sure under what circumstances such node is passed to MatchesSelector(), but I had to short-circuit here because objMatchesSelector() doesn't understand what a !!null node is.

I'm happy to remove this check on kind and add a check for !!null to objMatchesSelector() instead, in case someone feels strongly about it.

[antoineco]

See previous comment for the reason for this removal.

[imjasonh]

Thanks for adding this! This looks fine to me, @jonjohnsonjr do you have any comments?

[jonjohnsonjr]

I'm not enough of a yaml engineer to have a strong opinion about this, lgtm if you think it's fine.