fix: Determine how FASTStyle cache should work in SSR infrastructure

[nicholasrice]

@microsoft/fast-ssr implements a stylesheet cache to work with the FASTStyle custom element to reduce the stylesheet payload. When a stylesheet is first encountered, the sheet gets assigned an ID and the stylesheet content is emitted. When the stylesheet is encountered in subsequently, no stylesheet content is emitted because the sheet has already been sent to the client.

This caching behavior can lead to an interesting issue where, when there are multiple requests for a page, the stylesheet content is only sent to the first requestor, deferring to the cache in subsequent request responses. The approaches I've come up with to address this are:

A way around this currently is to create a new TemplateRenderer for each request:

Documentation:
The package exports a factory function to help avoid singleton issues like this. Perhaps it's enough to document the behavior, and advise to construct a new renderer for each response:

import fastSSR from "@microsoft/fast-ssr";

function requestHandler(request, response) {
    const { templateRenderer, defaultRenderInfo} = fastSSR();
    const result = templateRenderer.render(myTemplate, defaultRenderInfo);
    // ...
}

Implement a cache-busting method:
We could implement some cache-busting mechanism on the StyleRenderer (class responsible for rendering the styles) to purge the cache. Authors would need to invoke this when they saw fit:

import fastSSR from "@microsoft/fast-ssr";

const { templateRenderer, defaultRenderInfo, styleRenderer} = fastSSR();
function requestHandler(request, response) {
    const result = templateRenderer.render(myTemplate, defaultRenderInfo);
    // ...
    styleRenderer.cache.clear();
}

I'm not entirely happy with either of these approaches, so if folks have other ideas I'm all ears.