Feature request: skaffold run --command (or exec)

### Scenario

The (related) possibility of a `skaffold exec` command has been discussed before (eg in #252 ) but in that case it added little, and was kind of discussed in the abstract.

I feel like there are some concrete use cases for a `run --command` or `exec` style addition to the CLI, which causes skaffold to
- start services in a cluster
- with one of them started with an arbitrary command
- stop services again on exit

### Background

I'm trying to redeploy a django app using skaffold. So I have a 'dev' setup which runs postgres, redis, pgadmin, and of course the webserver.

In django, part of the development workflow is to execute utilities with management commands. Running a management command essentially starts the application, does the thing, then stops the application.

The obvious one is `runserver` and so my `web-deployment.yaml` file has the section
```
metadata:
labels:
module: web
spec:
containers:
- name: django
image: octue/drift
args:
- python
- manage.py
- runserver
- 0.0.0.0:8000
```
All I do is `skaffold dev --port-forward` and the database, cache, everything comes up beautifully.

But, another common one is `python manage.py makemigrations` which starts the server, checks the database's state, then makes database migration files. Other commands reset the database, flush caches, open up a shell into the django environment, etc etc...

These require resources like the database to be up but not the 'default' server. They may even require no other server not to be running, e.g. if doing surgery on the database.

### Expected behavior

Something like
`skaffold run --command web -- python manage.py makemigrations` to start a cluster and instead of the default command on the web container, use the specified one.

### Actual behavior

No option to do so.

Mostly, the work around is:
`skaffold dev`

`kubectl get pods`

`kubectl exec -- python manage.py makemigrations`

to kill

But this doesn't work for commands where another server cannot be connected to the database... and is a screaming agony of a workflow, because the pod name changes every time you type anything.

### Information / Steps to reproduce the behavior

I can create a repo with a detailed example, if it helps.

### A grander vision

This feature could actually propel a whole bunch more use cases for skaffold, because at that point you would have an elegant way of creating command line tools that operate with specific sets of resources locally and are redeployable to the cloud trivially.

This could be great for scientific research - scientists tend not to be devops experts at all. They'll hack around some code, run, re-run, re-re-run, re-re-re-run it locally, get some cool analyses running - then face an extraordinary uphill struggle turning that into a deployed webservice. But supplying a template with skaffold in it would allow them still to monkey around locally for R&D purposes, but actually on a well defined, stable and portable infrastructure.