Review behaviour of matchers when encountering `unsupported` filters

[peteski22]

Is your feature request related to a problem? Please describe.

Currently when matchers run on registry packages and encounter an unsupported filter key, we log a message via the logFunc, then return that it's not a match.

Describe the solution you'd like

... should we just continue and not return a false match?

This might clean up things as we also rely on calling code clearing/deleting filters that we don't support.

mcpd/internal/provider/mcpm/registry.go

Lines 110 to 117 in 6c20891

	// Handle lack of 'version' support in mcpm.
	if v, ok := fs[options.FilterKeyVersion]; ok {
	r.logger.Warn(
	"'version' not supported on resolve operation, returning latest known definition",
	"name", name,
	options.FilterKeyVersion, v)
	// Clear 'version' for mcpm as it cannot be used.
	delete(fs, options.FilterKeyVersion)

Documentation needs to be reviewed/created/updated to explain matching (differences in which filters are any, all, etc).

Describe alternatives you've considered

No response

Additional Context

No response

Self-Checklist

• I have read the Contributing Guidelines.
• I have searched the existing issues and found no duplicate.
• I have provided a clear and concise description of the problem.
• I have provided a clear and concise description of the proposed solution.