provide support for dotnet tool install -U / --upgrade

[damageboy]

Steps to reproduce

$ dotnet tool install -g dotnetsay --version 2.1.3   
You can invoke the tool using the following command: dotnetsay
Tool 'dotnetsay' (version '2.1.3') was successfully installed.
$ dotnet tool install -g dotnetsay --version 2.1.4
Tool 'dotnetsay' is already installed.

Expected behavior

dotnet tool install should allow a proper upgrade switch / command to avoid the needless (and less script friendly) workaround to always try to do dotnet list -g => dotnet tool uninstall -g => dotnet tool install -g for a simple upgrade

Actual behavior

Upgrade doesn't magically happen.

Environment data

.NET Core SDK (reflecting any global.json):
 Version:   2.1.302
 Commit:    9048955601

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.302/

Host (useful for support):
  Version: 2.1.2
  Commit:  811c3ce6c0

.NET Core SDKs installed:
  2.1.302 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[ThatRendle]

There is an upgrade command:

dotnet tool upgrade -g dotnetsay

[damageboy]

I know, but as far as I can tell I can't specify the version on the update, it seems geared to updating to the latest stable.

I am looking for a fool proof way of installing a bunch of dotnet tools as part of an orchestration script.

So ideally, I have something that is idempotent, I run dotnet .... --version 3.1.4 and whatever the current state is, I get the desired version...

Does that make sense?

Again, I'm stressing that this is the default state with apt: apt install xxx=3.1.4 and pip: pip install -U numpy=1.14 as examples

[livarcocc]

@peterhuene @wli3

[wli3]

Please continue comment this issues if you think dotnet/cli#10205 cannot solve the problem of your scenario and I will reopen it

[damageboy]

dotnet/cli#10205 is a great fix for this issue as far as I'm concerned thanks!