`unique_domain!` macro can be used to generate multiple domains with the same family

`unique_domain!` will generate a unique type for every macro invocation, however, if the resulting code is executed multiple times, multiple domains with the same family can be created. This is trivially possible if the code is placed inside a function or loop, since the macro is only expanded once, but the resulting code is executed multiple times.

```rust
let mut v = vec![];
for _ in 0..2 {
v.push(unique_domain!());
}
```

I don't see an easy solution here, esp. not at compile time.

I don't see any way to force a macro invocation to only be executed once at compile time, so we will need either need to find a way to return the same domain each time (i.e. the example will generate two pointers to the same pointer), or error (at runtime) when the generated code is called a second time.

1. We could trivially add an internal static `AtomicBool` to track whether a given macro has been called multiple times. This is not ideal, since it means using `unique_domain!` inside a function, such as a constructor, is no longer possible.
2. If we are okay with just always returning the same domain, (i.e. the above example would generate a vector of pointers to the same domain), we can make this work better. This has a few downsides - it forces multiple instances of data structures that use a custom internal domain to share the domain. We should also likely wrap the shared Domain in a custom Arc-like wrapper, which triggers the domain to eagerly reclaim retired pointers when the domain pointer is dropped.

The first option is restrictive, and will cause certain use-cases to require unsafe code. (The current implementation can cause UB in these cases). The second has performance implications, but should be safer.
It's trivially possible to make the value returned by `unique_domain!` a static reference, but the implications of this need to be explored before we settle on an option for this.

Start with the `unique_domain!` macro and reproduce the loop example that creates multiple domains with the same family. Read through the two proposed semantics—rejecting repeated execution or returning a shared domain—and determine the safety, ownership, and performance implications. Done means the repeated-execution behavior is defined and the resulting implementation avoids the reported undefined behavior.

Written by the indexing model from the issue text.