Refactor script to separate out starting and updating zwift

[hobeone]

As described in pull request #94 it would be good to split out the code that starts Zwift vs the code that updates it. Filling a bug to understand the background and requirements.

@netbrain what did you want to get out of this refactor?

[netbrain]

The entrypoint script has two responsibilities today.

1. Update game files, which it does on the first run, or when update argument is present.
2. Start Zwift.

Would be good to split this into a update.sh and a start.sh. this would further modularize this solution and make it possible for reuse in other use cases.

[hobeone]

Working through this now.

Is there a reason that the script exits after installing? I would expect it to install Zwift if it isn't already there and then start it.

[netbrain]

It's probably due to how the github actions are set up and how we build the zwift container (which you know contains all game files)

So first we run the "empty zwift image" which runs with the update flag and simply downloads the latest zwift files. Then we commit's that container instance to a new image i.e zwift:latest and zwift:.