feat: each service instance to use its own binary

The `add` command will download a copy of `safenode`, and if no version was specified, it will be
the latest version at the time the command was run. If the command is used a day later to add
another service, that could then be a different version. If both nodes were using the same binary at
the same location, one would inadvertently be upgraded. There may also be issues with updating a
binary that is running.

For the upgrade process, it also seems logical and safer for each service instance to have its own
binary. If the upgrade process failed for one service, for whatever reason, it wouldn't leave
anything else in an inconsistent state.

It's also possible at some point in the future that it could be desirable for people to run
different node versions. Perhaps they would want to test a new version before moving from something
stable.

This also fixes a bug with the `--peer-id` argument where it will return an empty list of peers if
there is an error. This allows for no peers to be specified, which is necessary in the case of the
genesis node.