Strongly couple the SSM::Impl lifecycle to its enclosing SSM.

Currently the SSM::Impl is held by shared_ptr and has a different lifespan from its enclosing SSM, which is undocumented and will be a source of confusing bugs because Impl is supposed just be an information hiding device, not a separable entity with a distinct lifespan. So while the Impl is being kept alive by lambda callback anchors and interacting with the rest of the system, the system might reasonably assume the associated SSM is alive, which it isn’t.

Replace SSM’s shared_ptr<Impl> with a unique_ptr<Impl>, and use shared_ptr aliasing when necessary, so that a shared_ptr<Impl> will count as a reference to its enclosing shared_ptr<SSM>.

Remove std::enable_shared_from_this base class from SSM::Impl. Add it to SSM instead.

Callback anchors in Impl should be generated with a function that performs a shared_from_this on the enclosing SSM and produces an aliased shared_ptr<Impl> from it, so you still get a shared_ptr<Impl> but it hold a ref on the whole SSM.

This might be responsible for BF-22149, an unsolved BF in SEPImpl wherein an invalid iterator is used to erase an SSM. No direct evidence for this, but the lifespan issue feels like it could be relevant, since the dangling list iterator is bound to a callback held by the SSM::Impl as its cleanupHook, but is used to remove an SSM from a list. It's very suspicious in light of this ticket here.