Clear repo

To be able to perform the migration, we need to start from an empty directory/repo.

vendor/github.com/go-logr/logr/README.md

@@ -1,36 +0,0 @@
-# A more minimal logging API for Go
-
-Before you consider this package, please read [this blog post by the inimitable
-Dave Cheney](http://dave.cheney.net/2015/11/05/lets-talk-about-logging).  I
-really appreciate what he has to say, and it largely aligns with my own
-experiences.  Too many choices of levels means inconsistent logs.
-
-This package offers a purely abstract interface, based on these ideas but with
-a few twists.  Code can depend on just this interface and have the actual
-logging implementation be injected from callers.  Ideally only `main()` knows
-what logging implementation is being used.
-
-# Differences from Dave's ideas
-
-The main differences are:
-
-1) Dave basically proposes doing away with the notion of a logging API in favor
-of `fmt.Printf()`.  I disagree, especially when you consider things like output
-locations, timestamps, file and line decorations, and structured logging.  I
-restrict the API to just 2 types of logs: info and error.
-
-Info logs are things you want to tell the user which are not errors.  Error
-logs are, well, errors.  If your code receives an `error` from a subordinate
-function call and is logging that `error` *and not returning it*, use error
-logs.
-
-2) Verbosity-levels on info logs.  This gives developers a chance to indicate
-arbitrary grades of importance for info logs, without assigning names with
-semantic meaning such as "warning", "trace", and "debug".  Superficially this
-may feel very similar, but the primary difference is the lack of semantics.
-Because verbosity is a numerical value, it's safe to assume that an app running
-with higher verbosity means more (and less important) logs will be generated.
-
-This is a BETA grade API.  I have implemented it for
-[glog](https://godoc.org/github.com/golang/glog). Until there is a significant
-2nd implementation, I don't really know how it will change.