Migrate to use go mod

[iNecas]

While trying to learn Go, I was searching for some interesting project to play
with and get some experience on how does it feel to do something real in it.
While browsing through the code, I've noticed that the version of docopt locked
in Gopkg.lock
(https://github.com/oragono/oragono/blob/8e027fb58f4e9cb85cc04f3ca72526e3b4f88d57/Gopkg.lock#L17)
doesn't correspond with the version being vendored.

Compare
https://github.com/docopt/docopt.go/tree/784ddc588536785e7299f7272f39101f7faccc3f
with
https://github.com/oragono/oragono-vendor/tree/77ddc3dbc1ec085c73670510a8fece80599741ce/github.com/docopt/docopt-go

It seemed to me that migrating to Go 1.11's modules might be a way to fix this
and actually get to something that looks like preferred way of dealing with go
deps in 2018.

Please note that this is my first Go contribution and I have more
or less no idea what I'm doing. Feedback welcome. Also, feel free to close the
PR if you're not in favour of this change: no hard feelings.

Steps performed:

1. go mod init
2. rm -rf Gopkg.* vendor
3. go get -u
4. update Makefile, as the vendoring was removed

[DanielOaks]

Ah, very interesting. I'll have a play on this end, make sure it all works as expected and merge it in. If we can do it this way rather than needing to rely on the vendor dir then I'd be very happy to do so. Thanks for the contribution and for bringing this up!

[slingamn]

This is good work; our dependencies are a mess!

I have general concerns about go mod and the left-pad problem. That is to say, what recourse do we have if one of our dependencies is taken offline, temporarily or permanently? Is it a problem that the code can't be built without access to the public Internet?

If go mod is replacing dep as the preferred dependency management solution, then we should use it (although we might consider waiting until the interface is fully stable in 1.12). However, we might want to continue using a vendor/ directory with go mod vendor and GOFLAGS=-mod=vendor, as described in the FAQ.

[iNecas]

I understand the concerns. Also, when starting using the mod version, I've hit some issues around tooling (see mdempsky/gocode#46 and golang/go#24661), at the end, I was able to to get working the things I'm using, but I takes some time before the full support is there (probablye the reason why it's still experimental).

I think getting to use go mod vendor might be a good way for clean up the dependencies a bit a keep the project up to date with the trends in the go community. I will try to update this PR to use that (I will probably need to open PR into oragono-vendor as well).

[slingamn]

I also saw golang/go#27227 , which speaks directly to a concern I had about GOFLAGS=-mod=vendor being cumbersome to use. I think it might actually be beneficial to postpone work on this until that issue (and other related issues) are resolved, which will probably be in 1.12.

Let me also say that we're very grateful for your interest in the project! If you're looking for other potential areas to contribute in, I could make suggestions (or you could drop into #oragono on freenode, Dan and I are usually around).

[DanielOaks]

fwiw I plan to leave this PR open, because while I do see us moving to go mod (and the work here being useful), we'll need to work out the vendor stuff once it's more clearly sorted in prod. Thanks again for the contribution, much appreciated :)

[slingamn]

We finally did this. Thanks for the guidance!