Refactor repository layout and convert build system to Mage.

This commit implements a massive refactor of the repository, and
moves the build system over to use Mage (magefile.org) which should
allow seamless building across multiple platforms.

tools/vendor/github.com/tmthrgd/go-bindata/README.md

@@ -0,0 +1,189 @@
+# go-bindata (forked by tmthrgd)
+
+[![GoDoc](https://godoc.org/github.com/tmthrgd/go-bindata?status.svg)](https://godoc.org/github.com/tmthrgd/go-bindata)
+[![Build Status](https://travis-ci.org/tmthrgd/go-bindata.svg?branch=master)](https://travis-ci.org/tmthrgd/go-bindata)
+[![Go Report Card](https://goreportcard.com/badge/github.com/tmthrgd/go-bindata)](https://goreportcard.com/report/github.com/tmthrgd/go-bindata)
+
+This is a rewrite of go-bindata that started life as fork of a fork. It
+was forked by [lestrrat](https://github.com/lestrrat/go-bindata) as
+[jteeuwen](https://github.com/jteeuwen/go-bindata) seemed to have
+abandoned the project.
+
+Since that fork, go-bindata has been
+[largely rewritten](https://github.com/tmthrgd/go-bindata/compare/3adb6a8b66f07a123c3d44e8f6c7e78bbdd029c2...master)
+and has become a standalone project. While the generated code has changed,
+the generated API remains backwards compatible. The
+[package API](https://godoc.org/github.com/tmthrgd/go-bindata) is not
+backwards compatible. The CLI remains backwards compatible, but may not be
+as feature complete as the package API.
+
+The suggested way of using go-bindata is from a single .go file with an
+ignore build tag (`// +build ignore`) run with
+`//go:generate go run path/to/generate.go`. (See
+[issue #2](https://github.com/tmthrgd/go-bindata/issues/2#issuecomment-290957538)
+for reference).
+
+*Nota bene*: Most of the README that follows has not been updated to match
+the changes made since rewriting go-bindata and likely does not accurately
+represent the state of go-bindata.
+
+## bindata
+
+This package converts any file into manageable Go source code. Useful for
+embedding binary data into a go program. The file data is optionally gzip
+compressed before being converted to a raw byte slice.
+
+### Installation
+
+To install the library, use the following:
+
+	go get -u github.com/tmthrgd/go-bindata/...
+
+### Accessing an asset
+
+To access asset data, we use the `Asset(string) ([]byte, error)` function which
+is included in the generated output.
+
+	data, err := Asset("pub/style/foo.css")
+	if err != nil {
+		// Asset was not found.
+	}
+
+	// use asset data
+
+
+### Debug vs Release builds
+
+When invoking the program with the `-debug` flag, the generated code does
+not actually include the asset data. Instead, it generates function stubs
+which load the data from the original file on disk. The asset API remains
+identical between debug and release builds, so your code will not have to
+change.
+
+This is useful during development when you expect the assets to change often.
+The host application using these assets uses the same API in both cases and
+will not have to care where the actual data comes from.
+
+An example is a Go webserver with some embedded, static web content like
+HTML, JS and CSS files. While developing it, you do not want to rebuild the
+whole server and restart it every time you make a change to a bit of
+javascript. You just want to build and launch the server once. Then just press
+refresh in the browser to see those changes. Embedding the assets with the
+`debug` flag allows you to do just that. When you are finished developing and
+ready for deployment, just re-invoke `go-bindata` without the `-debug` flag.
+It will now embed the latest version of the assets.
+
+
+### Lower memory footprint
+
+Using the `-nomemcopy` flag, will alter the way the output file is generated.
+It will employ a hack that allows us to read the file data directly from
+the compiled program's `.rodata` section. This ensures that when we
+call our generated function, we omit unnecessary memcopies.
+
+The downside of this, is that it requires dependencies on the `reflect` and
+`unsafe` packages. These may be restricted on platforms like AppEngine and
+thus prevent you from using this mode.
+
+Another disadvantage is that the byte slice we create, is strictly read-only.
+For most use-cases this is not a problem, but if you ever try to alter the
+returned byte slice, a runtime panic is thrown. Use this mode only on target
+platforms where memory constraints are an issue.
+
+The default behaviour is to use the old code generation method. This
+prevents the two previously mentioned issues, but will employ at least one
+extra memcopy and thus increase memory requirements.
+
+For instance, consider the following two examples:
+
+This would be the default mode, using an extra memcopy but gives a safe
+implementation without dependencies on `reflect` and `unsafe`:
+
+```go
+func myfile() []byte {
+    return []byte{0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a}
+}
+```
+
+Here is the same functionality, but uses the `.rodata` hack.
+The byte slice returned from this example can not be written to without
+generating a runtime error.
+
+```go
+var _myfile = "\x89\x50\x4e\x47\x0d\x0a\x1a"
+
+func myfile() []byte {
+    var empty [0]byte
+    sx := (*reflect.StringHeader)(unsafe.Pointer(&_myfile))
+    b := empty[:]
+    bx := (*reflect.SliceHeader)(unsafe.Pointer(&b))
+    bx.Data = sx.Data
+    bx.Len = len(_myfile)
+    bx.Cap = bx.Len
+    return b
+}
+```
+
+
+### Optional compression
+
+When the `-nocompress` flag is given, the supplied resource is *not* GZIP
+compressed before being turned into Go code. The data should still be accessed
+through a function call, so nothing changes in the usage of the generated file.
+
+This feature is useful if you do not care for compression, or the supplied
+resource is already compressed. Doing it again would not add any value and may
+even increase the size of the data.
+
+The default behaviour of the program is to use compression.
+
+
+### Path prefix stripping
+
+The keys used in the `_bindata` map, are the same as the input file name
+passed to `go-bindata`. This includes the path. In most cases, this is not
+desirable, as it puts potentially sensitive information in your code base.
+For this purpose, the tool supplies another command line flag `-prefix`.
+This accepts a portion of a path name, which should be stripped off from
+the map keys and function names.
+
+For example, running without the `-prefix` flag, we get:
+
+	$ go-bindata /path/to/templates/
+
+	_bindata["/path/to/templates/foo.html"] = path_to_templates_foo_html
+
+Running with the `-prefix` flag, we get:
+
+	$ go-bindata -prefix "/path/to/" /path/to/templates/
+
+	_bindata["templates/foo.html"] = templates_foo_html
+
+
+### Build tags
+
+With the optional `-tags` flag, you can specify any go build tags that
+must be fulfilled for the output file to be included in a build. This
+is useful when including binary data in multiple formats, where the desired
+format is specified at build time with the appropriate tags.
+
+The tags are appended to a `// +build` line in the beginning of the output file
+and must follow the build tags syntax specified by the go tool.
+
+## Testing
+
+To execute the test case, run the following commands:
+
+	go get -t -u github.com/tmthrgd/go-bindata
+	go test github.com/tmthrgd/go-bindata
+
+### Test corpus
+
+To generate the corpus-sha256sums needed for travis, run the following commands:
+
+	[ -d .testcorpus ] && rm -r .testcorpus
+	go test -run TestCorpus -randtests 50 -corpus .testcorpus -gencorpus .
+	cd .testcorpus && sha256sum * > ../corpus-sha256sums; cd ..
+
+This must be done every time the generated code changes, but can be skipped while working
+on a pull request until it is ready to merge.