<!--
  Please provide a clear and concise description of what the bug is. Include
  screenshots if needed. Please test using the latest version of the relevant
  React packages to make sure your issue has not already been fixed.
-->

React version: 18.0.0-beta-149b420f6-20211119

## Steps To Reproduce

1. render a context with `react-test-renderer` (wrapped in act)
2. render the same context with `react-dom/server`

<!--
  Your bug will get fixed much faster if we can run your code and it doesn't
  have dependencies other than React. Issues without reproduction steps or
  code examples may be immediately closed as not actionable.
-->

Link to code example: https://codesandbox.io/s/react-18-react-test-renderer-react-dom-server-forked-lbs7j?file=/package.json:189-219
```js
const Context = React.createContext(null);

function Component({ renderer }) {
  return (
    <Context.Provider value={renderer}>
      <div />
    </Context.Provider>
  );
}

let testRendererRoot;
ReactTestRenderer.act(() => {
  testRendererRoot = ReactTestRenderer.create(
    <Component renderer="react-test-renderer" />
  );
});
ReactTestRenderer.act(() => {
  testRendererRoot.unmount();
});

ReactDOMServer.renderToString(<Component renderer="react-dom/server" />);
```

## The current behavior

`renderToString` results in the console error "Warning: Detected multiple renderers concurrently rendering the same context provider. This is currently unsupported."


## The expected behavior

No error like in React 17 (https://codesandbox.io/s/react-17-react-test-renderer-react-dom-server-yr8gx).
Considering all renders are wrapped in their corresponding `act` I don't expect that I'm concurrently rendering. 

I tried to understand when we reset the `rendererSigil` (responsible for checking if we "concurrently rendering") is reset and it seems like we never reset it but only initialize it when creating the context (`createContext`)
So it either seems like multiple renderers in the same module are not supported anymore or the reset is missing.


// uses this flag to know that the remaining ancestor providers have already
  // been propagated.
  //
  // NOTE: This optimization is only necessary because we sometimes enter the
  // begin phase of nodes that don't have any work scheduled on them —
  // specifically, the siblings of a node that _does_ have scheduled work. The
  // siblings will bail out and call this function again, even though we already
  // propagated content changes to it and its subtree. So we use this flag to
  // mark that the parent providers already propagated.
  //
  // Unfortunately, though, we need to ignore this flag when we're inside a
  // tree whose context propagation was deferred — that's what the
  // `NeedsPropagation` flag is for.
  //
  // If we could instead bail out before entering the siblings' begin phase,
  // then we could remove both `DidPropagateContext` and `NeedsPropagation`.
  // Consider this as part of the next refactor to the fiber tree structure.
  workInProgress.flags |= DidPropagateContext;
}
export function checkIfContextChanged(
  currentDependencies: Dependencies,
): boolean {
  if (!enableLazyContextPropagation) {
    return false;
  }
  // Iterate over the current dependencies to see if something changed. This
  // only gets called if props and state has already bailed out, so it's a
  // relatively uncommon path, except at the root of a changed subtree.
  // Alternatively, we could move these comparisons into `readContext`, but
  // that's a much hotter path, so I think this is an appropriate trade off.