Adds the ability to clone only and not fork

[sledigabel]

This is a follow up of #49.

With this commit, the clone command is defaulting to cloning and
forking only when the user has not push rights onto the repository.

If the --fork flag is specified, it will fork and clone
systematically.

[sledigabel]

Just noticed there'll be a bug here:
https://github.com/Skyscanner/turbolift/blob/main/cmd/create_prs/create_prs.go#L77

In the case of a gh fork the fork will be called origin and the upstream will be called upstream.
In the case of a gh clone with a fork, it will be called fork and origin.

After testing, I believe this line can be removed.
This is taken care of by the gh command automatically, it will test if the user has write access.
Testing...

[sledigabel]

We have a problem...

the gh client is quite smart (too smart) with its own logic.
the clone is virtually the same as a git clone but the gh pr create is quite advanced.

https://github.com/cli/cli/blob/trunk/pkg/cmd/pr/create/create.go#L532-L590

Basically the logic is:

• get the pr title body etc.
• check if the remote is compatible with push
• check if the repo is pushable (the magic is right there
• if you can't write to it, then the CLI proposes to create a fork using the API from a TUI.

Unfortunately that TUI is not programmable so bad luck.
I'd suggest two courses of actions:
A. look at the API layout and replicate the same mechanism but at clone time rather than PR time.
B. update the gh cli and add some more options to the gh pr create and avoid this TUI thing altogether to make it more interfaceable.

At this stage, and having looked at this for a little while now, Option A is prob the easiest one.
I actually think it's worth the effort, as it would make it quite a smooth experience.

One downside of using the TUI and the current gh behaviour is that the result forked repo created is named "forked", and the main one is still called "origin". So then it's on the user to basically handle this and push to origin or fork when needed.
Option A would simplify this too, all the pushable repos would end up being called "origin" (after the fork, you end up with a upstream/origin paradigm).

[sledigabel]

Bottom line of this is that it's a lot more complicated than previously anticipated.

After discussing with Richard (@rnorth) a while back, the best course of action for now is to:

• Systematically fork
• Propose an alternative to always clone with a flag.

It adds some value, as most users will either have full access to the target repos or no access.
If the users encounters a case where they have a mix of both, forking still works.

We can spend some more time refining the logic behind when using clone and forking. For now the gh client logic is not enough as we don't know ahead of time which one will be needed, and programmatically create the fork.

[JimNero009]

LGTM.
Adds the ability to unilaterally choose to not fork. Implementation for a conditional 'fork only if needed' turned out to be much more complicated than originally thought, so this provides a solution for the subset of cases where a user has full access to all repos they wish to change, which is valuable.