Specifying a sort order when returning unique values

As discussed https://github.com/data-apis/array-api/pull/25#issuecomment-681129564, we need to resolve if, and how, we should specify a sort order when returning unique values.

A corollary issue is, if we support an optional keyword to return sorted unique values, whether we should also support specifying the sort direction (ascending vs descending).

We could limit sorting to ascending order, but that this may be considered an arbitrary restriction may lend support for the argument of not returning ascending/descending sorted output at all. Instead, punting sorting to userland, where sort order can be specified via sort(). However, as discussed in the OP, combining unique/sort may allow implementation perf optimizations which cannot be replicated when performed as two separate steps.

[asmeurer]

Sorting is also not well defined for complex dtypes (potentially for other advanced dtypes as well if those were ever added). See https://github.com/data-apis/array-api/issues/102#issuecomment-748328170. I’m not clear what the final resolution of that is, but it sounds like the sort function and friends require additional complexity to properly handle complex numbers (e.g., a key parameter). So it would probably be a good idea to omit sorted from any non-sorting API functions, as they would also have to support those additional parameters to be usable with complex dtypes.

[rgommers]

Makes sense, thanks @asmeurer. There are no other sorted keywords at the moment other than in unique (which gh-104 removes).