Support custom fetching/filtering specification for `InstancesSelectEditor`

[jsheunis]

Problem statement by @mih :

why it would be futile to give in to the desire to just add more classes, and what we might need instead
...imagine we have a slot that takes Person, but the only meaningful ones are INM7 Members. Or Document, but only those that are "grant proposals".
The only means we have to make that happen are dedicated classes (INM7Member, GrantProposal). However, it is impossible to express the world in a single class hierarchy (think category systems vs tagging systems). Moreover, LinkML doesn't understand multiple inheritance (and no, mixins do not work).
So the only tool we have (range -> class) is not fit for the job.
Worse: the slot values are just PIDs. There is no meaningful type checking beyond that.
So we have all the awkwardness of a class hierarchy to deal with, and no benefits.
IMHO this is the issue.

Solution? I am not convinced that this is a modeling issue, hence not convinced that anything in the model (LinkML) can solve it.
One way to think about this is: editing hints.

When the UX issue is to have to filter a list of 30k organizations, or hundreds of documents in order to make discovery/selection more practical: let's solve that issue. And we can solve this in shacl-vue IMHO
I believe that many use cases for such filters are fairly simple. A person that is part_of something with a specific PID. Or a document that is kind of something with a specific PID.

Implementation wise I am not sure what is simple to achieve. If the triple-store in shacl-vue has SPARQL, this might be the most straightforward/generic approach. Take all instances that match range, and run them through a simplistic SPARQL query, and show only those that make it through.
Such queries/filter expressions would go into the shacl-vue config.

I think the most impactful example of this problem is files (by number and diversity). Most of what we deal with is in files. Looking at the number of, e.g. mimetypes, it is clear that any file type distinction on a class/type level is insane, unless there is a rather narrow use case. Hence something like mimetype or format is just an attribute. Hence wanting to only present tabular data for a particular slot requires exactly this type of filtering. If this needs to be supported (and I think there is no way around that when we have millions of files), then offering the same selection approach to any class comes at very little cost.

Comments by @jsheunis:

The InstancesSelectEditor, the component that would be responsible for showing this filtered set of records, has been moving in the direction of receiving more config options that influence how the list is generated, so this development would be in line with that. We could also consider slot annotations that would provide these specifications, as an alternative (or addition) to the deployment config approach. Annotations could be useful in generalized cases that won't differ across deployments

There's currently no SPARQL in anything. The triple store, which uses N3, supports fast store queries which I use already for all graph-related operations in shacl-vue. The question for me is rather how this would interact with fetching data from the backend. Ideally we should fetch the least amount of records, so it might be good idea (to be explored) to apply the constraints already to the request made to the backend.

[jsheunis]

f30526c brought the ability for the user to filter the list of items by class. No other filtering capability is currently available.