Add a new endpoint `customProperties` to support retrieving `customProperty` values only

[dhirajsb]

Is your feature request related to a problem? Please describe.
As a companion to #1460 model registry should support retrieving just the customProperties for all resources, i.e collections like /experiments and individual resources like /experiment/{id}.

In addition, it should support the following query parameters:

• resourceType: experiment, experiment-run, etc. (required) Use an enumeration to identify all resource types (super set of ArtifactType enumeration).
• resourceId: optional ID of a resource, if not provided the endpoint can fetch customProperties across all resourceType resources.
• nameOnly: boolean param to retrieve only names of customProperties
• distinct: return only distinct values.
  There may not be any utility or use case for returning duplicates in any scenario, and hence always true to retrieve distinct values.
• filterQuery: support filtering on the resourceType just as it would filter records of the resourceType/[resourceId] endpoint.
  E.g. /customProperties/?resourceType=experiment&nameOnly=true&distinct=true&filterQuery=org-name='my-org' would retrieve customProperty names for all experiments belonging to the org my-org identified with customProperty org-name=my-org.

Note that the return response will only have an item list with customProperties without information about which property belongs to which resource if used without a resourceId. This endpoint is only meant to get all customProperties, or only names for any resource.

Describe the solution you'd like
Add a new endpoint /customProperties endpoint for all resources, e.g. for collections and individual resources to retrieve just the customProperties.

Describe alternatives you've considered
Another alternative to adding a single shared /customProperties is to add a /customPropertes endpoint for every resource endpoint. It would avoid having to specify resourceType and resourceId parameters, inferring them from the path instead. But it trades 2 query parameters for API bloat (N new endpoints for N resources) without any actual difference in behavior.

Less useful but use case specific alternatives like /customPropertyNames endpoints were considered, but lack the utility of being able to fetch just the customProperties, or just the names or distinct collections of either, which are all supported by the proposed solution above.

Additional context
Relates to the simplified API response and performance improvement enhancement for all endpoints in #1460

[dhirajsb]

CC @jonburdo

[Jp3132]

/assign

[dhirajsb]

Hi Jay, thanks for offering to take this issue. But work was already being done on it and it requires detailed knowledge of the server.
@jonburdo are there any other simpler issues @Jp3132 can start with?

[jonburdo]

We still need to come up with a list of good first issues. Sorry I don't have anything on the top of my head!