Merge baget fork back to liget

[tomzo]

TL;DR since 1.0.0 LiGet will be a fork of BaGet. Read lower why...

We have previously created and used LiGet from various pojects, just to get it working on dotnet core.
When BaGet started to look promissing, we contributed some work there with indention to migrate from LiGet to BaGet and obsolete the project.
However, following was deal-breaker:

• What we consider critical basis for mature project was not merged:
  • build must be reproducible, which in current .Net world means paket.lock commited in source repository.
  • released product must be built CD-style. Which in short means to build artifacts only once, and run them through a pipeline of tests and QA. It is not acceptable to run dotnet build or dotnet publish several times for same commit. There must be a well-defined set of binaries which were tested through all pipeline stages.
  • if docker is released then docker image must be tested with end-case tests running actual nuget clients.
• long feedback time for PRs in BaGet. I spend only a few days at time to get job done. I cannot wait weeks for review.

How is this fork different from upstream BaGet:

• using FAKE for build system, rather than scripting in MsBuild.
• added unit, integration tests and e2e tests with paket and nuget cli.
• we use docker and CLI tool IDE to create reproducible development environment for LiGet.
• added release cycle and testing of docker image using continuous delivery practices.
• implements read-through cache as separate endpoint. Which at the time does not work upstream.
• uses paket and FAKE for build system.
• uses Carter for routing rather than bare Asp routing.
• adds ability to log to graylog
• adds V2 implementation from old LiGet
• caching proxy has different endpoint /api/cache/v3/index.json than private packages /api/v3/index.json

Notes

• This will be merged once there is a seamless upgrade process from <1.0.0 and all e2e tests are passing.
• If anyone has any reason why not merge this, then please says so.