Add addon-update command

Enable users to change (upgrade/downgrade) an addon's plan.

I opted for a single `addon-update` command rather than separate `addon-upgrade` and `addon-downgrade` commands since those do the exact same thing under the hood anyway.

I've also currently designed this so that you only need to specify the plan name (i.e. `crane`) rather than the `service:plan` combo (i.e. `heroku-postgresql:crane`). It feels annoyingly redundant to me to need to specify the add-on's name (i.e. `heroku-postgresql-cobalt`, which is required by v3) and also have to specify the service name in this command, especially since you can't change the service, only the plan.

One downside of this approach is that it will make tab completion for this command a little more difficult since I'd have to first read the addon's name, then try to offer plans which are appropriate to the add-on being updated. Especially since that lookup would be dependent on the value of the `-a` flag, and I can't really use that in completions since it won't necessarily have been provided yet. Alternatively, I could read the name arg and attempt to guess what the provider name is and use that for completion. That would be a pretty straightforward and effective hack, though it wouldn't be guaranteed to work in all cases (especially if addon names diverge from the `provider-color` model).

```
➜  ~  hk addons
heroku-postgresql-cobalt  heroku-postgresql:crane  Mar 25 17:02
redistogo                 redistogo:nano           Apr  2 14:41

➜  ~  hk addon-update redistogo small
Updated redistogo to small on myapp.

➜  ~  hk addons
heroku-postgresql-cobalt  heroku-postgresql:crane  Mar 25 17:02
redistogo                 redistogo:small          Apr  2 14:52

➜  ~  hk addon-update heroku-postgresql-cobalt kappa
error: Upgrade for heroku-postgresql is not supported. Please provision a new plan instead.
```

/cc @max @brandur @friism @bjeanes for feedback