Don't gzip openrpc files for friendlier git wrangling

[rvagg]

The .gz files are impossible to rebase/merge/etc. but the files are needed in the repo for go build because they are embeds; so we just don't gzip them. In this format they are also pretty-printed JSON, so they'll merge very nicely, but they are not compressed.

The trade-off here is that the files are embedded in the go builds, so we get larger binaries, here's the differences:

• lotus = 238 Mb (new) vs 236 Mb (old)
• lotus-miner = 223 Mb (new) vs 221 Mb (old)
• lotus-worker = 158 Mb (new) vs 156 Mb (old)

(They all include all of the files, even if they don't use them, we could change that if we wanted because it's only full that's huge)

As @Stebalien was pointing out today, the reason we include these files at all in the library is so that go build theoretically works. Currently the only thing standing in the way of being able to use lotus as a library is the FFI, removing these files entirely would add another blocker to supporting that. See also (I believe) filecoin-project/filecoin-ffi#209

[Stebalien]

I looked into making the build faster as well by avoiding goimports and... it just made a mess. I think the right way forward is to make it possible to call make -j16.

[snadrus]

Could we provide a redirect or proxy to these files in some static place?

If a release is dev, no. But it's rare someone is writing code off these in dev anyway, right?

So, for regular releases, we just 302 to where these files should live in some static folder that relates to our current version.

Then, it's part of the release process to copy these files to the static place that we store params.

[snadrus]

Accepted, but please determine if the protocol & users see these as optional.
If so: gitignore + custom build rule + docs for those that need it.