Issue title: Deploy from Git URL
 Issue body: We can create an app with a Git repo (creds maybe) and push it without uploading a tarball first.
The Git info is stored in or referenced from the application resource.
 Comments: 
 Comment 0: Acceptance criteria:

  - Extended `push` command taking
      - Repository url
      - Access credentials (read-only, optional)
    The command skips tarball upload, and submits the above information instead (new API endpoint?)
    Server saves the information in a secret whose owner is the application resource.
    The staging endpoint checks for such a secret.
    If present it uses the information found as source location, instead of the standard gitea repo.
  - Sample application in the epinio org, sibling to epinio itself
  - Extended acceptance tests with test cases exercising the new functionality. This uses the sibling sample application as origin.

 Comment 1: Research findings:

  - [Upload code](https://github.com/epinio/epinio/blob/14c682e34b0c3c07fc2c2251d2f3cfd3f49dedb8/internal/cli/clients/client.go#L1164-L1183), this is what we have to skip.
  - :zap: Staging already uses an explicit [Git Reference](https://github.com/epinio/epinio/blob/14c682e34b0c3c07fc2c2251d2f3cfd3f49dedb8/internal/cli/clients/client.go#L1194) in the stage request - See [Model](https://github.com/epinio/epinio/blob/14c682e34b0c3c07fc2c2251d2f3cfd3f49dedb8/internal/api/v1/models/app.go#L82-L85).

So. Maybe we simply have to create such a GitRef from `push` options instead of what we get from the upload endpoint, and staging will work with the external repo ?

Would we still have to save that git ref in the cluster, as part of the app ?
I.e. are there commands which currently simply assume `gitea` ?

If yes then it should also be easy to implement a WIBNI, of printing the external location from `app show`.
Not in scope right now.

 Comment 2: Looking at a traced `push`, the log contains

> 2021/06/30 14:21:56 EpinioClient/Push "level"=4 "msg"="upload response" "Name"="hello" "Organization"="workspace" "Sources"="assets/sample-app" "response"={"git":{"revision":"1edb2fcd477d8d647358d20367077536b6a1315f","url":"http://gitea-http.gitea:10080"}}

That looks good.
 Comment 3: Syntax ideas:

  1. `push --sources URL` ... Specification of a path as well, i.e. `push --sources URL PATH` becomes an error.
      Revision is specified either as part of the URL (what separator ?), or a separate option.
  2. `push --git REV URL` ... Here the revision is specified by an option, which also activates git mode.
      The URL takes the place of the PATH argument used by regular mode.

I currently consider option 2 the better.
It allows me to specify both revision and repo url in a natural manner.
The user cannot forget to specify just the location, without revision.

Other opinions about good/bad point of these ideas ? Other ideas ?




 Comment 4: Ok. First attempt fails (constructed git ref looks ok).

Something in the tekton pipeline still believes that the sources are in gitea.

```
021/06/30 15:19:09 EpinioClient/Apps "level"=2 "msg"="application logs" "Application"="hax" "Organization"="workspace" 
🕞  [441962c18a6e64be-clone-hjrfb-pod-jjw9c] step-git-source-source-repo-g44zr {"level":"warn","ts":1625059162.8359816,"caller":"git/git.go:277","msg":"URL(\"http://gitea-http.gitea:10080/workspace/hax\") appears to need SSH authentication but no SSH credentials have been provided"} 
🕞  [441962c18a6e64be-clone-hjrfb-pod-jjw9c] step-git-source-source-repo-g44zr {"level":"error","ts":1625059163.1869798,"caller":"git/git.go:54","msg":"Error running git [fetch --recurse-submodules=yes --depth=1 origin --update-head-ok --force main]: exit status 128\nremote: Repository not found\nfatal: repository 'http://gitea-http.gitea:10080/workspace/hax/' not found\n","stacktrace":"github.com/tektoncd/pipeline/pkg/git.run\n\tgithub.com/tektoncd/pipeline/pkg/git/git.go:54\ngithub.com/tektoncd/pipeline/pkg/git.Fetch\n\tgithub.com/tektoncd/pipeline/pkg/git/git.go:149\nmain.main\n\tgithub.com/tektoncd/pipeline/cmd/git-init/main.go:53\nruntime.main\n\truntime/proc.go:204"} 
🕞  [441962c18a6e64be-clone-hjrfb-pod-jjw9c] step-git-source-source-repo-g44zr {"level":"fatal","ts":1625059163.187124,"caller":"git-init/main.go:54","msg":"Error fetching git repository: failed to fetch [main]: exit status 128","stacktrace":"main.main\n\tgithub.com/tektoncd/pipeline/cmd/git-init/main.go:54\nruntime.main\n\truntime/proc.go:204"} 
🕞  [441962c18a6e64be-clone-hjrfb-pod-jjw9c] step-stage 2021/06/30 13:19:24 Skipping step because a previous step failed 
2021/06/30 15:19:25 EpinioClient/Apps "level"=1 "msg"="return" "Application"="hax" "Organization"="workspace" 
2021/06/30 15:19:25 EpinioClient/Push "level"=1 "msg"="return" "Name"="hax" "Organization"="workspace" "Sources"="https://github.com/epinio/example-wordpress" 
error pushing app to server: waiting for staging failed: Tasks Completed: 1 (Failed: 1, Cancelled 0), Skipped: 3
```

Ah! [Setup of repo ref](https://github.com/epinio/epinio/blob/14c682e34b0c3c07fc2c2251d2f3cfd3f49dedb8/internal/api/v1/stage.go#L254-L255) and [GitURL method](https://github.com/epinio/epinio/blob/14c682e34b0c3c07fc2c2251d2f3cfd3f49dedb8/internal/api/v1/stage.go#L254-L255) conspire to completely ignore the url part of the incoming git ref. Only the revision is used.




 Comment 5: And :tada: 
{'source': 'GithubIssues', 'repo_name_with_owner': 'epinio/epinio', 'issue_id': 926201070, 'repo_stars': 288.0}