What type of PR is this?
/kind bug

What this PR does / why we need it:

The list of tolerations on a pod is effectively represents a union of the taints tolerated by each, so it is entirely reasonable to have 2 tolerations like:

- key: foo
  operator: Equal
  value: bar
- key: foo
  operator: Equal
  value: baz

However, the old logic would consider those 2 tolerations a conflict, and overwrite one with the other in a merge.

This PR fixes the toleration helper methods to represent a logical merge and comparison. It does that by recognizing that some tolerations are supersets of others, due to wildcard matches. For example, the above tolerations would be redundant if there was a 3rd toleration: {"key": "foo", "operator": "Exists"}.

These fixes are needed to better support RuntimeClass scheduling, but also affect the alpha PodTolerationRestriction admission controller.

Special notes for your reviewer:

There are 2 design decisions I want to highlight, and am open to discussion on:

1. The decision to "smart merge" - Since tolerations represent a union, we could perform the merge by simply appending one list to the other (and maybe eliminating exact duplicates). We still need the isSuperset logic for checking the whitelist though, and I feel that simplifying with the smart merge offers a cleaner user experience.
2. TolerationSeconds - The eviction logic actually takes the minimum toleration time. So technically a lower toleration time would be the superset of a higher time. However, I don't think that was the intention (that logic probably wasn't considering duplicate tolerations for the same taint, but rather across all taints), so I've stuck with using the maximum toleration time for the superset. I think that is more inline with the intention of both the PodTolerationRestriction and RuntimeClass admission controllers (probably irrelevant for the latter).

Does this PR introduce a user-facing change?:

Fix an issue with toleration merging & whitelist checking in the PodTolerationRestriction admission controller.

/sig scheduling
/sig node
/priority important-soon
/milestone v1.16

I wasn't sure who to assign this to, so went with the original author and reviewers:
/assign @aveshagarwal
/cc @timothysc @smarterclayton @derekwaynecarr @davidopp @liggitt