define openapi schemas for meshmodel component and relationship summary filters

[Amr-Shams]

the meshery pr (meshery/meshery#917) adds summary filter apis for components and relationships in the registry. reviewers (@lekaf974 , @aabidsofi19 ) agreed that the filter/response structs should live in meshery/schemas as the source of truth, not in the meshery repo directly.

looking for alignment on the schema design before updating the existing pr (#616).

proposed schemas:

• ComponentSummaryFilter filter params (model, category, registrant, annotations)
• ComponentSummary response with grouped entries
• ComponentGroupEntry single group row (key + count)
• RelationshipSummaryFilter filter params (model, kind, type, subtype)
• RelationshipSummary response with grouped entries
• RelationshipGroupEntry single group row (key + count)

open question from gemini review: the generated Summary structs use anonymous structs instead of reusing GroupEntry types should the schema use $ref to the entry type to avoid duplication in codegen output?

ref: meshery/meshery#917, #616, #615

[welcome]

Thanks for opening this issue. A contributor will be by to give feedback soon. In the meantime, please review the Contributors' Welcome Guide, engage in the discussion forum, and be sure to join the community Slack.

[Junnygram]

can you assign me @lekaf974