for interfaces that extend another, reorder properties in API reference pages

[jgravois]

currently we alphabetize the properties associated with an interface.

example: url and updates are listed last in IUpdateFeaturesRequestOptions

it'd be substantially easier to grok the doc for the individual interfaces that extend IRequestOptions in particular if we consistently used the following order.

1. required
2. optional
3. inherited

bonus points if we could bubble up unique properties all the way to the caller doc page.

[jgravois]

i took some time to look into this this afternoon and its going to be a bit tougher than i thought to implement the fix.

i didn't have a problem applying the sort when we create the typedoc.json that powers the site.

children.sort(function (a, b) {
  if (!a.flags.isOptional && b.flags.isOptional) {
    return -1;
  }
  if (a.flags.isOptional && !b.flags.isOptional) {
    return 1;
  }
  return 0;
})

the problem is that by that point, each corresponding object already has an id assigned and that is what acetate uses when it creates the actual table.

arcgis-rest-js/docs/src/api/_declaration.html

Lines 105 to 106 in 415508c

	{% for id in group.children %}
	{% set child = API_TOOLS.findChildById(id, children) %}

i'm gonna have to chew on this more.

[jgravois]

@patrickarlt.

i think implementing your suggestion in #137 (comment) is the single most important thing that could be done to more successfully onboard new users/contributors.

i 🙏 you'll have a cycle sometime soon to take a crack at:

• inlining requestOptions properties in the API reference page for methods
• reordering properties so that required params are listed before optional parameters and inherited parameters are listed at the bottom

[jgravois]

resolved via #531

for those following along at home, the relevant code can be found in docs/src/build-typedoc.js: rankChild().