Fix zeroed buffer getting flushed to the empty event

fix goLevelDBIterator

call go env GOPATH if env var is not found (Refs #60)

```
WARNING: staticcheck, gosimple and unused are all set, using megacheck instead
db/go_level_db.go:126:15:warning: infinite recursive call (SA5007) (megacheck)
db/go_level_db.go:135:17:warning: infinite recursive call (SA5007) (megacheck)
db/mem_db.go:106:2:warning: redundant return statement (S1023) (megacheck)
```

https://circleci.com/gh/tendermint/tmlibs/220

Also remove unnecessary return statement

WIP: Improve db interface

add metalinter to CI and address some lint warnings

Develop

db: fix MemDB.Close

This is needed because leveldb reuses the keys on each iteration.
In our wrapper, we copy the key/value so that it is safe to store.

We need this to properly support LevelDB backend, which needs
to be released if we don't want to leak memory.

Fixes https://github.com/tendermint/tmlibs/issues/55

MemDB previously mistakenly set the actual DB pointer to nil
although that side effect is not visible to the outside world
since p is an identifier within the scope of just that function
call. However, @melekes and I had a discussion in which we
came to the conclusion that Close for an in-memory DB should
instead be a noop and not cause any data loss. See the
discussion on https://github.com/tendermint/tmlibs/pull/56.

common: WriteFileAtomic use tempfile in current dir

v0.3.0

call fsync after flush

short: flushing the bufio buffer is not enough to ensure data
consistency.

long:
Saving an entry to the WAL calls writeLine to append data to the
autofile group backing the WAL, then calls group.Flush() to flush that
data to persistent storage. group.Flush() in turn proxies to
headBuf.flush(), flushing the active bufio.BufferedWriter. However,
BufferedWriter wraps a Writer, not another BufferedWriter, and the way
it flushes is by calling io.Writer.Write() to clear the BufferedWriter's
buffer. The io.Writer we're wrapping here is AutoFile, whose Write
method calls os.File.Write(), performing an unbuffered write to the
operating system, where, I assume, it sits in the OS buffers awaiting
sync. This means that Wal.Save does not, in fact, ensure the saved
operation is synced to disk before returning.

See https://github.com/go-kit/kit/issues/164 for discussion of why
kitlog returns an error.

```
Package log is designed to be used for more than simple application info/warning/error logging; it's suitable for log-structured data in an e.g. Lambda architecture, where each invocation is important. I agree with you that if we were doing only application logging the error would be more noise than signal. But the scope of the package is larger than that.
```

Since we are doing only application logging and we're not checking
errors, it is safe to get rid them.

Log tweak

common/IsDirEmpty: do not mask non-existance errors

Fix rename /root/.tendermint_test/consensus_replay_test/priv_validator.json.new /root/.tendermint_test/consensus_replay_test/priv_validator.json: no such file or directory

[pubsub/query] quote values using single quotes

Currently IsDirEmpty returns true, err if it encounters
any error after trying to os.Open the directory.
I noticed this while studying the code and recalled a bug
from an earlier project in which doing the exact same thing
on code without permissions would trip out and falsely report
that the directory was empty.
Given demo.go in https://play.golang.org/p/vhTPU2RiCJ

* Demo:
```shell
$ mkdir -p sample-demo/1 && touch sample-demo/2
$ echo "1st round" && go run demo.go sample-demo
$ sudo chown root sample-demo && sudo chmod 0700 sample-demo
$ echo "2nd round" && go run demo.go sample-demo
```

That then prints out
```shell
1st round
original:: empty: false err: <nil>
updated::  empty: false err: <nil>
2nd round
original:: empty: true err: open data/: permission denied
updated::  empty: false err: open data/: permission denied
```

where in "2nd round", the original code falsely reports that
the directory is empty but that's a permission error.

I could write a code test for it, but that test requires me to change
users and switch to root as a Go user so no point in complicating our
tests, but otherwise it is a 1-to-1 translation between shell and Go.