Update `dotnet version` to work more like `build` and other baked in dotnet tools

[nover]

Meaning that if you run this in a folder where a .sln is present, parse the given solution to find all the csproj files, and then simply apply the specified bump to all of them (much like we're discussing in #68 ) to make it much simpler to do versioning in "mono repos".

This would mean that the "recursive" option becomes default which is a breaking change, but I think we should leave the -f flag intact so that people can target single files still.

So just like build:

• If we're located in a folder with a .sln file, it will just work
• If there are multiple solution files it has to bail, and you will have to specify which solution file to work on.
• If it is in a folder with a project, it should also just work and apply to that csproj file (which is current behaviour)
• If no csproj if found either, bail, and allow user to specify project file via command line flags

If there are multiple csproj files found due to sln discovery, and there is ambiguity in the version numbers discovered, we can ask the user which version that is the "master" and align the versioning in the csproj files - while respecting non-interactive settings in terminals and simply bail.

[nover]

For Debian we have to respect:

• DEBIAN_FRONTEND=noninteractive
• It seems like redhat/centos stacks do not have this