storage: prep ChangeReplicasTrigger for atomic rebalancing

The implementation plan for atomic rebalancing is to first expose a
testing-only API that lets us carry out general atomic membership
changes (i.e. not limited to a single swap which is all that we
expect to want to use in production in 19.2).

This allows us to really stress the machinery in general and also
prevents more API headaches down the road should we want to support
more general changes. Besides, the change to an API that supports
a single swap only is already similarly invasive.

This is the first in a sequence of PRs/commits that plumb the API
through the system (but without actually supporting atomic changes yet).
The whole pipeline that needs to be plumbed is

- `AdminChangeReplicasRequest` which calls into
- `(*Replica).ChangeReplicas` which calls into
- the internal code adding learners, sending them snapshots, etc, and
  which finally evaluates into a
- `ChangeReplicasTrigger` that needs to eventually be translated
  into a
- `raftpb.ConfChangeV2` (we use a v1 `ConfChange` today).

This particular change deprecates the `Replica` and `ChangeType` field
of the trigger, and introduces instead two slices of ReplicaDescriptors,
one for added and one for removed replicas. This will be easy to
translate into a `ConfChangeV2` and seemed more idiomatic (and less
error-prone) than including the base desc and computing a sequence of
changes from that whenever it is needed. It also matches what the higher
levels of the API will do.

As a drive-by, also remove ConfChangeContext.Replica, which has been
unused essentially forever (<2.0).

Release note: None