Add label list sorting and remove command - #5503

This includes much of PR #5452 and I'll rebase onto trunk after that's merged. For now, take a look at https://github.com/cli/cli/pull/5503/files/d24e632f29c0ac12e69cee7c8323c6820a5978f9..HEAD. I figured given time zone difference, I'd give a head start for expediency.

@heaths Thanks for getting this work started. I am still reviewing but I wanted to discuss the platform limitation regarding having both a search query and sort clause. As you suspected these two options are somewhat incompatible. I dove into the implementation and what is happening is that when there is a query phrase the platform uses elasticsearch to perform the search. Elasticsearch does its own scoring based on the search terms used and then will return the results based on best matches according to the score. Elasticsearch also supports sorting these results by created_at date but not by name. I am not sure why that is.

With this information I think we have three options for moving forward with this:

1. Use your current approach where gh always does the sorting when the query phrase is provided. This works but has two downsides that I can see. First, is that it has no way to leave the labels sorted according to elasticsearch score. Second, is that it does the sorting after the results are returned so there is a possibility that results would have been different than if they were sorted by elasticsearch and then truncated based on the limit.
2. We allow elasticsearch to do the sorting when "created" is selected and have gh do the sorting when "name" is selected. When "name" is selected this has the same downsides as above where the results are sorted after being returned.
3. We disallow using the sort/order and search flags together. Personally this is my choice, I think if a user is using --search to query labels they would most often want the results ordered by best match of their query term which is what this would give us. Additionally, this is what the web UI does.

What are your thoughts?

I like 3 as well. Straight forward and would retain what I imagine is a match-based sort order by default. After all, it is a search, not a filter. I'll go ahead and make those changes.

Rebased on trunk and removed the client-side sorting.