Add a typeMatcher for Secrets

**Describe the problem/challenge you have**
There's certain behavior that depends on the type of the secret (and potentially other objects that provide a type field). Current matchers don't allow to select only these resources. You need to resort to possible annotations present in these objects.

**Describe the solution you'd like**
A resource matcher that could match also by type, so that you could do explicit rules for the [different kind of secrets](https://kubernetes.io/docs/concepts/configuration/secret/#secret-types)

---
Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

The issue names no files, tests, or entry points. Start by locating kapp's existing resource matchers and their tests, then review Kubernetes Secret types and determine how a type-based matcher should be expressed. Done means explicit matching of the documented Secret types is supported and covered by tests.

Written by the indexing model from the issue text.