add .net core paket (and netstandard2.0 paket.core)

[enricosada]

add netcore unit tests and integration tests
publish .net core fdd paket in bin_netcore directory

changes:

• ProjectFile.AssemblyName for new sdk projects, can be implicit
• paket init .net core doesnt download the boostrapper, not supported
• disable System.Configuration.ConfigurationManager based on NO_CONFIGURATIONMANAGER
• replace non working WebClient proxy under CUSTOM_WEBPROXY define
• ServicePointManager.SecurityProtocol exists in netstandard 2.0
• the WebRequest.DefaultWebProxy cannot be used on .net core
  the IsBypassed throw "Operation is not supported on this platform."
  for now, is disabled for .net standard, but need something to reenable it based on framework of runtime

add .net core fdd paket in tools/netcoreapp2.0
the paket.exe is duped in tools/net45

[enricosada]

@forki for me is ok to merge.

• is green, tests pass (unit and integration).
• appveyor is splitted in two jobs (one only .net ) so it will not block you if you need to release

[forki]

ok how do we want to release this?

[enricosada]

@forki nothing special atm. this was mostly to:

• add to CI and maintain parity, so i dont need to merge conflit too much.
• add to Paket nupkg

the Paket.nupkg now contains two additional directories:

• tools/net45
• tools/netcoreapp2.0

what's missing to finish the full .net core scenario is the boostrapping part. working on that from now on. got some ideas, need to test. paket scenario (before restore, boostrap, etc) and release management
(fast, github+nupkg, hash, magicmode) is really unique, so...

meanwhile, i want to test the .net core version on real world. how?

with a temporary (but stupid) way to boostrap paket, for alpha testing.

• to testrestore step. i'll add in some real world proj (need to ask for help from maintainers there) a parallel job in appveyor/travis. so normal job use normal .net paket. the other use the .net core version.
• at user side (to test install and others commands). a way to update paket easy, and use the same version of current one used in the repo, but .net core.

ihmo this type of testing is really good, because discover lots of bugs, without taxing the beta testers for manual testing. And their normal flow use the normal .net paket, so is stable.

my next steps:

1. i'll finish the repo tool PR. i'll use that as the stupid boostrapper. now that this PR is merged, the Paket nupkg can be used already as repo tool, targeting both net and netcoreapp. so user can install that, and just run paket from shell.

2. when repo tool is merged (really soon). start do the parallel testing thing, with help of beta tester

3. meanwhile work on boostrapper side. i think when this is done, paket will be already a lot stable, with help of beta testing.

[enricosada]

List of proposed beta tester:

• https://github.com/fsprojects/Mechanic (by @tlycken via FSF slack #dotnetcore chan)

[Porges]

Do you have an alpha of .NET Core Paket to try out? I'm porting https://github.com/hedgehogqa/fsharp-hedgehog to target .NET Standard, so now when we build on Linux we shouldn't need Mono installed (except we do, because Paket currently requires it to bootstrap! 🙂)