docs: Reference pages for service-router and service-resolver config entries

[boruszak]

Description

This PR updates the service resolver and service router configuration entry reference pages as part of the Consul Education team's IA efforts. These changes restructure the page to make information easier to find, and to promote a consistent layout between reference pages.

PR Checklist

• updated test coverage
• external facing docs updated
• appropriate backport labels added
• not a security concern

[boruszak]

Leaving questions on some specific items for verification from engineering SMEs.

[eddie-rowe]

Looks good overall to me.
Grateful for the directed comments - made it very accessible to contribute.

[trujillo-adam]

I didn't get 100% through everything but most of this looks really good. We should discuss it next week, but I think the decision to use tables for large sections of configuration parameters is, to some extent, conflicting with the format we are trying to establish. We discussed it earlier, but I was under the impression that the tables would be more the exception than the rule.

[trujillo-adam]

Suggested change

	| Parameter | Description | Data type | Default |
	| Parameter | Description | Data type | Default |

I think these params are better served as their own entries in the specification. Including the reason I mentioned in another comment about the control+f workflow, it also breaks the configuration model. We tell readers to click on a parameter to view it's details and the links to these parameters don't work. We could just link them all to #routes-destination, but I think it's a little counter to the spirit of the format we're trying to establish. For lower-nested configurations, it totally makes sense to place them into a table and link to the parent param, as in the Add, Set, Remove maps in the RequestHeaders and ResponseHeaders fields. But I think this is too much of a deviation from the format.

[trujillo-adam]

Looks great! I just saw one typo and had one suggestion about linking to an example from one of the params in the resolver spec. Also, we are only using the curly braces in the HCL headings because there isn't a shorthand for maps in YAML, correct?