Optimize for larger doc sets

[dnfield]

Semi-related to https://github.com/dart-lang/dartdoc/issues/1982

Today, dartdoc generates a full HTML page for each class, member, method, library, etc.

As of right now on Flutter, that's nearly 35,000 files and totals nearly 1GB of space (we further add to it by preparing offline versions as zip archives).

It should be possible to reduce that size by not repeating common content. All pages share a common footer and header, and most pages have very similar left hand navigation. For instance, every property of the Icons class has the same sidebar that lists all the other properties: https://master-api.flutter.dev/flutter/material/Icons/ac_unit-constant.html. Depending on how this is designed, it could have additional benefits such as not losing your scroll position in the left nav bar when jumping around class member definitions.

Managing this amount of content has introduced flakiness in our CI process, which tries to upload all of this data for master-api.flutter.dev on every merge commit. Some of that pain could be reduced if we had something like a common HTML shell, and scripts that defined (statically) the content to be placed on the page.

For what it's worth, I understand this is not an entirely trivial change :)

[dnfield]

In case its not clear - I'm requesting two optimizations:

1. Reduce the amount of repeated data overall in the docset. Let common content live in single files that reference each other (using something like <script>s or <iframes> or what-have-you).
2. Reduce the number of files generated overall. 35k files is hard for our hosting provider to negotiate during the upload.

[devoncarew]

For the first item, that does sound something like iframes. I don't know of the SEO indelibility of having scripts generate content.

In terms of the 2nd request, we've gotten that feedback before: https://github.com/dart-lang/dartdoc/issues/1272. I think this would be a useful change overall, not just for flutter doc generation. It may mean that we reduce the amount of content for each documented item - something like instead of in-lining the source code for an item, we instead link to github.