Add missing documentation for GCODE analysis and other small fixes

[dforsi]

Adds documentation for dimensions and printingArea; fixes length
and volume; adds two internal references.
Fixes #2463.

• Your changes are not possible to do through a plugin and relevant
  to a large audience (ideally all users of OctoPrint)
• If your changes are large or otherwise disruptive: You have
  made sure your changes don't interfere with current development by
  talking it through with the maintainers, e.g. through a
  Brainstorming ticket
• Your PR targets OctoPrint's devel branch, or maintenance if it's
  a bug fix for an issue present in the current stable version (no PRs
  against master or anything else please)
• Your PR was opened from a custom branch on your repository
  (no PRs from your version of master, maintenance or devel please),
  e.g. dev/my_new_feature or fix/my_bugfix
• Your PR only contains relevant changes: no unrelated files,
  no dead code, ideally only one commit - rebase and squash your PR
  if necessary!
• Your changes follow the existing coding style
• If your changes include style sheets: You have modified the
  .less source files, not the .css files (those are generated with
  lessc)
• You have tested your changes (please state how!) - ideally you
  have added unit tests
• You have run the existing unit tests against your changes and
  nothing broke
• You have added yourself to the AUTHORS.md file :)

What does this PR do and why is it necessary?

It adds some missing information.

How was it tested? How can it be tested by the reviewer?

make -C docs html

Any background context you want to provide?

What are the relevant tickets if any?

#2463

Screenshots (if appropriate)

Further notes

Now the structure of this JSON object is too complex to be rendered in a simple flat table. I'm open to ideas.
I don't think that it is easy to understand that the table above can describe a fragment like this (I may have made a mistake):

filament: {tool0: {length: 1407.434510000002, volume: 8.978582902758397}}

[foosel]

Shouldn't this rather be filament.tool{n}.length? Same with filament.tool{n}.volume below.

[foosel]

I think a flat table should still suffice, as long as the above issue is fixed.

I would expect people to also take a look at live data which should clarify things entirely. Or we could just include an example?

[dforsi]

You were right, I fixed the two filament.tool{n}... lines and forced a push.

Including an example would be useful, but only if you can add them in a form that can be tested, such as using unit tests as examples (maybe pulling the code in the .rst file with literalinclude), or deriving the json output from running actual code (maybe with doctest), so that only the tables are to be maintained manually, but I never used those directives. In some cases it would be better for the reader to see only some fields of a big object, however appending to each chapter an output with all possible fields would be easier to maintain, if you can derive it form the code.