SlotchangeNipSlip #3

1. During constructor(): The default state needs to be processed, because the relationship to the nested web component depends on an context dependent state (this.now). Although the relationship between sisyphus-list and sisyphus-item is known, this relationship builds on contextual data which is not accessible in HTML nor CSS template.
2. Both the sisyphus-list elements process this initial state. The first list, #lifeInGeneral, needs and will use the result of this process. But as we will see, #lifeAsAWebDeveloper does here do redundant work.
3. During attributeChangedCallback(): The default state needs to be processed again because the nested web components needs to be processed based on a per element specific state (this.dayMonth). If no attribute is set, no attributeChangedCallback() will be triggered. Without manually postponing the processing task, which is far from trivial, #lifeAsAWebDeveloper will here perform first re-processing of the sisyphus-items, making previous processing redundant.
4. During slotchange event listener: The second sisyphus-list, #lifeAsAWebDeveloper, however gets a slotchange event. In fact, it can somewhere between 4, 6 or 7, depending on the browser and your "debugger;" statements. What?! 4, 6 _or_ 7 slotchange events?! Depending on "debugger;"?! Yes... The mayhem that is RedundantSlotchangeCreations is discussed in SlotchangeNipSlip #4. For now, we simply say that at least one slotchange event was triggered.
5. The slotchange event listener will again need to reprocess the sisyphus-items, making the two previous processes of sisyphus-items redundant.
6. The SlotchangeNipSlip #3 problem is that: a) since sisyphus-list#lifeInGeneral gets no slotchange event nor attributeChangedCallback(), the sisyphus-list web component needs to process its flattened DOM children from the constructor(). b) sisyphus-list#lifeAsAWebDeveloper is instantiated with both an attribute and transposed nodes. This means that the sisyphus-list#lifeAsAWebDeveloper gets an additional attributeChangedCallback and at least on slotchange callback. sisyphus-list#lifeAsAWebDeveloper only needs process the last of these triggers.
7. As we will see later, the solution to SlotchangeNipSlip #3 is to control the timing of the slotchange reaction better, and to trigger the same reaction whenever a slot element instantiates itself (regardless of initial state). This will patch the problem of MissingInitialFallbackNodeSlotchange, along with the other SlotchangeNipSlip problems.