feat: Add ability to filter by resource labels and annotations

[avanish23]

Closes: #7547
Currently, the filtering is allowed by name only, for any resource.
With this PR intends to introduce support for filtering via various parameters

• name
• status
• label
• annotations
  and more.

How can this be done?
This will be done by comma ',' separated values. If the input does not have a comma-separated value, it will be filtered by name by default.
If a comma-separated string is provided then the convention followed should be property,value for example status,Running label,app=dashboard annotations,sidecar.istio.io/inject=true
For example, if the user input is:

• dashboard the pods filtered will be those that will contain "dashboard" in their name.
• name,dashboard,label,app=dashboard,status,Running the pods filtered will be have "dashboard" in their name, a label with key value pair "{app:dashboard}" and status is "Running"

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: avanish23
Once this PR has been reviewed and has the lgtm label, please assign maciaszczykm 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

[floreks]

The initial implementation was only meant to work with names. We wanted to take another pass at it. The main flaws of the current approach are:

• Filtering different fields based on string parsing does not make a good API. We should probably use an encoded array of objects that can define fields like: operation, field/property, value, etc. This way we could create more complex filtering queries by multiple fields with i.e. AND/OR operations.
• It does not use server-side filtering. The K8S API supports field-level filtering (name, status, labels). Annotations would probably be handled on our side.

I would prefer not to rely on current logic to not encourage anyone to extend it as it should be rewritten and optimized.