More docs coverage for User Ops arguments

[philrz]

The docs about User Ops arguments in #4663 seemed like an accurate summary for experienced Zed users, but I was concerned that newbies might require more detail to understand the flexibility/limitations. Here I've tried to expand on that section. I expect I may not have gotten this right on the first try, so here's my thinking in case it helps folks frame counter-proposals.

The phrase "path values" as we had it seemed too vague to me. Looking over what's already in the docs, the word "path" is sadly already a bit overloaded. For instance, we currently speak of "path" in the context of:

1. Parallel legs of a flowgraph (e.g., merge, combine, fork),
2. Storage locations on the filesystem/S3, or,
3. "Fields" when we describe how cast is used in shaping and with the fields and flatten functions.

Overload is sometimes inevitable and we usually rely on context to help make it clear. But since this is intro text about the very nature of arguments I think it helps to be detailed.

In the end, writing that up made me recall how in a group discussion someone mentioned that we might want to introduce the kinds of paths passed into User Op parameters as a "first-class" concept in the language. Indeed, that might have helped here since it would have given me something to link to and keep the text shorter. The one thing I see that comes close is the section on field dereferencing, but that's only written in the context of records, and I know there's more to paths than just finding fields in records (e.g., this could refer to a primitive, top-level value in the data stream). I chose not to boil the ocean and take on "first-class paths" right now, but instead I linked to that field dereferencing section as an example because it probably covers most of of the kinds of path references users will be making.

Coming up with the example used here gave me more time to think about if we should require explicit specification in a User Op's signature of expected parameter categories (e.g., const or path). By the time I was done, I'd flipping around to thinking they're probably not necessary. As I went through the docs, I struggled to find places where only a constant would be acceptable, since as I say in the new docs, expressions are often expected by our built-in functions/operators and therefore paths or constants will both evaluate ok. On the other hand, I was able to find a couple situations where only path references could work (e.g., the assignment I've done in the example here, or the drop operator). Since those restrictive cases are maybe the minority, per @nwt's point, maybe conventions (e.g., naming) alone could do the trick when this matters, so I've shown that in my example. If someone can think of a good example where the code inside the User Op will work only if the value passed in is a constant, I might change my thinking back yet again. 😄