make API docs request objects easier to understand and use

Nobody has claimed this yet.

## Overview ##

In this issue, I propose a few changes to make the API docs a lot easier to use so that one can effectively learn how to build a request object needed for each RPC call. Right now, all the items mentioned below are embedded in the description text, making it easy to miss something (especially because you need to manually click the **V** to expand the description for each field) and become frustrated because your RPC call isn't working right. The request object of some API calls have a large number of fields (`routerrpc.SendPaymentRequest` is a good example), making interpreting the documentation fairly tedious.

I think they would be much simpler to understand things if available in tabular form.

Right now in the docs, we have 4 fields

` Field | gRPC Type | REST Type | REST Placement `

but it would be nice to

## Mark which fields are required and which are optional ##

Some fields are required and some aren't. If we can add a column to the table to clearly differentiate, that would be nice. For example, expand the table to include

` Field | Required? | gRPC Type | REST Type | REST Placement `

where possible values are `Always`, `Never`, or `if X is also defined`.

In cases where we may have a choice between two required fields, I think we should just mark them all as required and the user will be required to look to see under what conditions it is required and what alternatives the field may have

In cases where we have nested requirements, such as `tapchannelrpc.SendPaymentRequest`, which require embedding a `routerrpc.SendPaymentRequest` inside of it, it becomes even more tedious trying to figure out what are the bare minimum number of fields that need to be populated in order for the request to be successful. Making the API docs easier to use is even more important in this case!

## Define field alternatives ##

Some fields have one or more options that can be used. We should be able to clearly know what we can use instead by looking to the right instead of reading through every field's description. For example, expand the table to include

` Field | Required? | Mutually exclusive with | gRPC Type | REST Type | REST Placement `

An example where we have multiple possible fields is in `routerrpc.SendPaymentRequest` which has `amt` and `amt_msat`.

## Define field defaults ##

Building further, it would be nice to state the default values in a column, rather than in the description text. For example, expand the table to include

```
Field | Required? | Default Value | Mutually exclusive with | gRPC Type | REST Type | REST Placement
```

Some fields have a default and some fields have no default. For example, `routerrpc.SendPaymentRequest` has a default `fee_limit_sat` of `0`, but `amt` has no default value.

The issue names no files, tests, or entry points; begin by locating the API-documentation generator in this Go repository and how it builds request-field tables. Done means the generated docs present requiredness, mutually exclusive alternatives, default values, gRPC type, REST type, and REST placement in a usable table.

Written by the indexing model from the issue text.