storage: Don't allow preemptive snapshots on initialized replicas

[a-robinson]

This prevents preemptive snapshots from silently succeeding, allowing a
replica GC to be intertwined with the creation of a new replica such
that the new replica has no local data.

Also add some verbose logging for replica ID changes.

---

This PR is honestly more questions than changes. The only real change is moving the r.mu.replicaID > replicaID check ahead of the replicaID == 0 check, and beyond that it's just an extra log statement and questions. Even that change requires some more investigation as it's caused the test to start occasionally timing out due to a failure to ever GC the removed replica (with not gc'able messages in the logs), which may or may not be an existing issue that rejecting the preemptive snapshots exposes.

I think we also need to do more than this since it's essentially just preventing preemptive snapshots from being applied to existing replicas, but I'm a little wary of making bigger modifications without fully understanding the reasoning/history behind why things are the way they are. In particular, the fact that a MsgHeartbeat can seemingly come in and create a replica that doesn't know its own key range which will then fail when it tries to process the heartbeat (as in #14231 (comment)) seems super dangerous, but there may be some reason for doing so that I haven't thought of.

Once the questions are resolved, this will:
Fix #14193
Fix #14231
Fix #12574

@cockroachdb/stability

---

This change is 

[bdarnell]

Historical note: we disallowed preemptive snapshots when there was an existing replica until #8613. There was debate about whether or not we should allow that in #7833 (I was of the opinion that it would be fine; @tschottdorf was more cautious).

[a-robinson]

Consider this replaced by #14306.