tab: Incorporate maverick cc into Dronefly

[michaelpirrello]

As discussed, migrate ,maverick customcom into a Dronefly command.

[michaelpirrello]

Consider ,my mavericks as a shortcut to a syntax like ,ids maverick by me (ids have other properties as well, like "leading" that could be the subject of other subcommands)

[synrg]

Unsure. It might actually be most usefully another ,tab (e.g. ,tab id <query-for-ids> per <ids-breakdown-keyword>) just like the other two cc's you requested be integrated (see #128 ), unless you feel there's value to listing/selecting individual ids from a large paginated list in Discord. if so, that would be ,s id.

[synrg]

And btw, that's ,id, not ,ids for the "returns a single match" form. So we could have three possible formats here, just like we do for observations: breakdowns per user (or per taxon, or per month, or whatever) would go under ,tab, whereas single "best" matching id would be ,id and ,s id would be to page through each individual id matching the query. I can see the utility here of all three for maverick. It's just a matter of which would be a good first target for introducing support.

[synrg]

I think the simplest implementation I could do here to get this started is ,tab id with maverick by me but without an actual table, i.e. just a URL with a link description like "Identifications with maverick by Michael Pirrello (michaelpirrello)" which links to those identifications on the web. The table would not support any reaction buttons as they don't make any sense in this context. As syntactic nectar for this, we could have ,my maverick be an alias for this.

In future, we can support identifications as something that can be listed in a table, i.e. a count by whatever breakdown is chosen: user for whom the IDs were made, place, taxonomic rank, month, etc. that links to the corresponding identifications on the web. However, that's a lot of things, and we'd need an issue per item and gradually build those things on top of this initial sparse display.

[synrg]

I went a different way with this. Since we don't have ,tab id to hang this under, I went with ,tab maverick as a subcommand. We could eventually incorporate maverick as an entity in the query language itself, but there are other pieces that need to be put in place first to make that work. It shouldn't be too tricky to make the transition later to maverick as a subcommand to maverick as a keyword that fits into the correct qualifier for a fully functional query that works with all the other qualifiers. In this initial version, maverick only supports by <user> and defaults to by me if you omit the argument.

In this form, I don't think ,my maverick is beneficial enough to be worth the added code (just a reduction of one character!) so I didn't add any ,my alias for this subcommand.

[synrg]

Feature delivered in 54c6ef9987604d4d66388d94b3670678ee971d83