More powerful list endpoint for additional search function

[nsheff]

In #4 we posed the idea that a user could use an alias (eg grch38) to find sequence collections with that alias.

We realized this could be made possible if we do 2 things:

1. Update the spec so that the /list endpoint MAY respond to a ?attr=value request where the attr is an array, by treating this as filtering to any seqcols where the the array attr contains value as one of its elements. Previously this wasn't really defined by the spec, but if we define it, then it makes the list endpoint a bit more powerful because it doesn't just look for exact matches.
2. introduce the aliases attribute to a collection, with a formal definition (it's an array of human-readable identifiers that could be searched in this manner).

Then you'd just search by saying ?alias=grch38. This more powerful list method could also be used for other attributes (like, "find all the arrays for which x is listed as one of the contributors", or even "find all the arrays where sequence digest xyz is in the list of sequence digests").

So we decided it could make sense to add this to the spec as a MAY extension for 1.1

The alias idea is also related to #79

[nsheff]

Questions:

• is this worth adding to the spec? Or is this just something someone needs to implement in one service? I guess if it was added, it would be optional.
• how would we distinguish between the 'equals' and 'contains' cases?

[nsheff]

In discussion today, we think this is interesting, and we should add it to the spec as an optional thing to do.

so the spec would just standardize the API interface (nothing to do with actual implementation of how it would work).

Idea, you POST to /list something in the form of a canonical seqcol.
the filter loops thorough, and then returns a list of collection identifiers that match ALL (AND) of the elements in your list.
no implementation or OR (just hit the endpoint twice)
we view this more as a mask.