[Project Sync] Remove optional argument for volume name

[grayside]

The presence of this argument means it is impossible to infer from the project config the name of the sync volume, which means creating tests is not possible. We can support special circumstances to override or change the volume name via config overrides as discussed in #72.

Unfortunately this would be a backwards compatibility break.

[febbraro]

I'm not sure I understand why this is a problem. Is it a problem because it is an argument and not an option? Would converting it to an option remove the problem? Can you explain it a bit more maybe with an example? (sorry 🙀 )

One of the main reasons it is here is so that you don't need a project config file to make use of a particular volume. I don't think this is in widespread usage, so it is probably ok to change how it is being used.

[grayside]

1. How do we test/doctor check that a volume exists for a given project, given this can ad hoc override what the project would use?
2. How do we create a command to manage the volume or container given there is non-contextual information driving what this could be called?

The crux of this is that the project perspective of this is mostly about rig magically handling filesync with a few outrigger.yml options to tweak behavior, but the parameters and arguments on the command are about using rig as a wrapper or a set of docker run commands.

I have been thinking about whether there is value in having a rig fs top-level command, and allowing rig fs sync to be the place where this is flexibly operated. (Incidentally, this might dovetail with #6). Then rig project sync focus on this as a polished, config driven product can be split from the other use cases of facilitating unison sync as an ad hoc/power user function.

[febbraro]

I see what you mean. I dont have particularly strong feels one way or another, and honestly I don't think that the sync:start [volume-name] is being used by anyone yet.