[1/3] Start a rexi_server per remote node

This is part of a multi-release upgrade to switch to using a rexi_server
instance per remote node. The first commit introduces the new
rexi_server instances, the second switches to using the new instances
and the third will remove the singleton rexi_server. Each of these
commits should be in a separate release.

The new pattern introduced by this commit will start a 'rexi_server_%b'
process where the '%b' is replaced by the `erlang:phash2(Node)` for
which it will service requests. After the second commit is release each
rexi generated message will be sent to the rexi_server instance on the
remote node handling requests for the local node. The
`rexi_utils:server_pid/1` function is used to generate the id of the
remote server.
[2/3] Start a rexi_server per remote node

Switch sending rexi messages to the rexi_server handling requests for
the local node. This replaces the use of the singleton rexi_server
process with a rexi_server instance for each node.

The only slight gotchya in the switch is that we need to send kill
messages to both the per-node and singleton instances during the
transition because we can't tell which process may have generated the
job. The extra kill message will be removed in the next commit.
[3/3] Start a rexi_server per remote node

Remove the rexi_server singleton from service. This is the last of the
three release cycle required to upgrade a cluster. Before releasing this
commit we should make sure the singleton isn't holding onto a large
number of jobs.