[CSS Modules] Adding "one and done" suggestions to Open Issues (#1146)

Per our conversation this morning, this change adds the "one and done" open issue (along with a suggestion to address it) in the Open Issues section. It also adds an open issue for how the `LinkStyle` interface should be handled and adds Steve Orvell to the References and acknowledgements section. Finally, it removes the open issue regarding Import Maps in shadow roots, as Domenic gave a response to that, so it's no longer an open issue.

Author: KurtCattiSchmidt

ShadowDOM/explainer.md

@@ -813,10 +813,12 @@ The following table compares pros and cons of the various proposals:
 ## Open issues
 * What happens if a `<template shadowrootadoptedstylesheets="">` references a specifier that was imported as a non-inline CSS module whose fetch hasn’t completed yet?
   Leading idea: Disallow any non-declarative imports on `<template shadowrootadoptedstylesheets="">`. This is the simplest approach that will minimize the possibility of an FOUC and non-deterministic behavior based on network timing, at the expense of flexibility. If mixing imperative and declarative CSS modules is a scenario we want to support, an alternative way of handling this case is that non-declarative imports are skipped when processing declarative shadow roots if their status is still "pending" at the time that the declarative shadow root is parsed. Otherwise they are applied in the same way as a declarative import.
-* Was it ever intentional that `<script type="importmap">` works inside a shadow root?
+* Should Declarative CSS Modules behave in a "one-and-done" fashion like JavaScript modules? This would mean that the first module parsed is always applied when referenced with its specifier, which differs from the steps described in [Detailed Parsing Workflow](#detailed-parsing-workflow). There are a few implications of this behavior, including that modifying the contents of the `<style type="module">` element wouldn't update the associated stylesheet in the module map, subsequent Declarative CSS Modules with the same specifier won't override the existing entry in the module map, and that a specifier on a `<style type="module">` element can never be changed. This behavior would bring CSS Modules more in line with JavaScript modules, but less in line with how the `<style>` tag currently behaves. If we proceed with this approach, one option for making these behaviors explicit is to remove the `<style type="module">` element from the DOM once it has been entered into the module map, which is similar to how `<template>` elements with declarative shadow DOM work. Removing the `<style>` element from the DOM would make most of the disallowed behaviors in a "one and done" scenario no longer possible.
+* Should the stylesheet for a declarative CSS module be accessible via JavaScript from the `<style type="module">` element? In regular `<style>` tags, it would be accessible and modifiable through the [LinkStyle interface](https://www.w3.org/TR/cssom-1/#the-linkstyle-interface). We may not want to allow this, particularly if the CSS Module approach is decided to be "one and done".
 
 ## References and acknowledgements
 Many thanks for valuable feedback and advice from other contributors:
 - Alison Maher
 - Alex Russell
 - Justin Fagnani
+- Steve Orvell