Fix appveyor integration by not using cake for build

[huoyaoyuan]

Fixes #6913 .
The key improvements: compiler and nuget warnings are populated, Xamarin projects are covered

I'm keeping in mind that making build configuration straightforward.
AppVeyor directly integrates to MSBuild. The configuration is quite simple.
Note that much more warnings are populated, including ones during restore and packing. It's very boring and hard to collection all them in cake.

InspectCode integrates very badly with the .NET Core world. It's strongly depending "desktop" MSBuild which is only accessible from Visual Studio Developer CLI, and supporting only Windows. Integrating it into the experience of VS will probably break command line on .NET Core. So I'm keeping the current progress with cake unchanged.

I also removed the "1 script to do what CI does at local", because:

• Many developers doesn't have Xamarin installed. Then they will require manually skipping them in the script.
• It's only possible to do exactly everything on Windows now.
• It doesn't fit the workflow, especially with IDE.
• User wants to fix violations instead of just prompting them, for example the dry run of dotnet format.

I've tried a lot at my local fork to make sure everything is working. Deployment is proved by the correct artifacts collected by AppVeyor. (https://ci.appveyor.com/project/huoyaoyuan/osu-deploy/builds/29081533/artifacts)

[huoyaoyuan]

Validated at my fork. The validation of deployment is a bit out of date. It requires to deploy to a fake environment.

[huoyaoyuan]

Deployment proved:
Build at https://ci.appveyor.com/project/huoyaoyuan/osu-deploy/builds/29099897
Package pushed to https://www.myget.org/feed/huoyaoyuan/package/nuget/ppy.osu.Game/1.2.3

[huoyaoyuan]

Changing the tests directory organization should be suitable for another PR.

[huoyaoyuan]

No: currently android test will fail on loading beatmap resource. Since no one is actually using it, let's delay it.

[huoyaoyuan]

AppVeyor does't allow mixture of propertyset and command line. Enabling WarningAsError without incluencing normal build requires explicit specifying everything.
Alternatively, I'm relatively OK with WarningAsError during normal development.
Or let AppVeyor "just work without regression" (not prompted at all -> reported to discord)?

[peppy]

I'm also not strongly against WarningAsError being always on.

@smoogipoo thoughts?

[huoyaoyuan]

Or a condition in csproj to detect weather it's built by appveyor, similar to what we did for referencing native libs from framework.

[smoogipoo]

I think it’s fine as always on. We’ve already had a warning in osu.Game that we’ve ignored for months.

[huoyaoyuan]

Windows build for iOS provides warnings, and is skipped now via solution configuration. Once ppy/osu-framework#3044 get resolved, it can have managed side covered by Windows pool.

[peppy]

let's give this a shot