Polish the zq command doc

[philrz]

In a recent community Slack thread, a new user began learning zq by reading the docs and asked:

is there a list of output formats? similar to this table of input formats?
https://zed.brimdata.io/docs/commands/zq/#input-formats

Indeed, I saw such a table did not exist. I then started reading the whole doc through the eyes of a new user and found several other things that also use some polish, including:

• A few more hyperlinks
• Improved formatting
• Coverage of some recently-added features

etc.

I'll include in-line comments in spots where I feel it would help to explain my motivation.

[philrz]

I went ahead and alphabetized the order in this table (and in the new table in the "output" section too). Looking at the history of this table, I know that at one time it was intentionally ordered by some sense of which formats would be most relevant to users. However, we now support many more formats and diverse use cases, and over time some of the "adds" here have often been alphabetical (e.g., arrows ending up first), so it had already become kind of "hybrid". We place enough emphasis in the doc on the biggies (e.g., ZNG/ZSON and how they relate to JSON) that it seems safe to just go with the alpha ordering we use for most things.

[philrz]

This is just a style thing, but I tend to reserve the fixed width font for things a user types, formal language constructs, names of shell tools, etc.

[philrz]

I imagine some folks may not love the repetition between this and the "inputs" table. There's a couple reasons I bit the bullet and added this.

1. The community user that kicked off this effort expressed a sense that they expected to see the table. The text that was there before said "The supported output formats include all of the input formats along with text and table formats", so I'd have hoped that was enough coverage. But I know that users can often be in a rush when consulting docs.

2. This is sort of a variation on the previous point, but given the section header hyperlinks for "Input Formats" and "Output Formats" in the right-hand side of the screen when viewing the rendered docs site, it is indeed a handy convenience to see the quick splash table with one click rather than having to do a "delta" exercise after clicking to another section.

3. Strictly speaking, we can't claim that the supported output formats include all of the input formats, since line is not an output format (incidentally, that's been requested by at least one user via Export data in line #5042).

[philrz]

This whole section is brand new and I kind of cooked it up out of thin air, so I'm definitely open to collaborative edits.

I've always been a little bothered that text and table are available, users fiddle with them at times (e.g., the community user that spawned this effort found issue #5154) but they have plenty of limitations/gotchas and aren't really documented anywhere that I can see. As I tried to touch on what I think of as the important points, I can tell that there's probably no way to be exhaustive short of telling users to go look at the code. Therefore I tried to cover what I think of as the biggies, wrap it in a note of mild caution, and assume interested users will hack and be tolerant.

I respect it's just long enough that it might be seen as interrupting the flow, so if there's an interest in moving it to another spot (maybe even in "Formats", since strictly speaking they're our own creation) I'm open to that.

[chrismo]

Cool! Thx for this. :)