Add meadow update command.

[CartBlanche]

Command to reduce customer paper cuts when needing to update Meadow.CLI.
It is easier for customers to remember meadow update, which will update to the latest version, rather than remembering:

> dotnet tool update WildernessLabs.Meadow.CLI --global

We could also allow them to roll back to specific versions, should something break or become unstable in vLatest. Obviously not too far back as then meadow update wouldn't be available.

Tested on:

• Windows
• Mac
• Linux

When run on Mac and Linux this is the output:

16:36:35 ~/Downloads $ meadow update
Updating WildernessLabs.Meadow.CLI
This will initially uninstall WildernessLabs.Meadow.CLI and will then install version vLatest
Please wait about 10s to allow the above steps to complete.
16:36:50 ~/Downloads $ Tool 'wildernesslabs.meadow.cli' (version '2.0.47') was successfully uninstalled.
Skipping NuGet package signature verification.
You can invoke the tool using the following command: meadow
Tool 'wildernesslabs.meadow.cli' (version '2.0.48') was successfully installed.

[adrianstevens]

It doesn't make any sense to wrap another CLI call in our CLI

[CartBlanche]

It doesn't make any sense to wrap another CLI call in our CLI

I've always thought that the idea of wrapping this particular CLI call (or other complex CLI calls) is to minimise the paper cuts our customers encounter when using the Meadow stack, by having to remember the long MS command as well as the correct parameters required. Also the meadow update was a feature @bryancostanich asked if it was possible, in a thread on Slack (link it today's weeklies).

We already simplify the lives of our customers with our own CLI wrapper of the dfu-util CLI here -
https://github.com/WildernessLabs/Meadow.CLI/blob/develop/Source/v2/Meadow.Dfu/DfuUtils.cs
Where we both automate the installation of dfu-util with meadow install dfu-util and when we call meadow firmware write. As well as on Mac with a wrapper around ioreg CLI command. So I'm not deviating from what we already provide for our customers.

It seems easier for customers to remember meadow update, which will update to the latest version, rather than remembering:

> dotnet tool update WildernessLabs.Meadow.CLI --global

We could also allow them to roll back to specific versions, should something break or become unstable in vLatest. Obviously not too far back as then meadow update wouldn't be available.

[adrianstevens]

Let's make the updater and stand-alone app. I don't think it needs to be called from the Meadow.CLI console app since it's already it's own app.

[CartBlanche]

@adrianstevens just to be clear the Meadow.CLI needs to shell out then shutdown for the updater app to actually then perform the update. So are you suggesting that the updater app be in it's own repo or something else??

[ctacke]

Updates to the build actions should not be in with code changes. If this had been a stand-along PR, it would have already been merged.

[ctacke]

I'm also in the camp of "this is not a good idea". If we're simply trying to make it easier a user who forgets the command, why not just echo out the proper command for them? Creating a new command that creates a new process and calls some other existing CLI seems clunky AF

[bryancostanich]

This was my fault. Users kept running into issues with the update and i asked for this feature but didn't realize what a cluster it would be.