feat(render): overhauled qri render, implement RFC0011

[b5]

OOooOOok, this PR implements RFC0011.

There are a few other changes worth pointing out:

Qri viz template syntax has changed

This PR completely breaks the existing viz template api, replacing it with the one the RFC describes. I plan to fully document that API & post it up in the next few days. The majority of it is outlined in the RFC.

limit, offset and all params are removed from render

Good riddance. Instead templates now bear the full responsibility of determining how much of the dataset body to read. This is a necessary change now that save and update both execute render by default. Speaking of which:

qri save and qri update both generate visualizations by default

Qri now stores an executed version of the template at index.html. Get the old behaviour back with --no-render.

[ramfox]

I was having trouble installing this. Turns out dataset and starlark both import a package github.com/360EntSecGroup-Skylar/excelize. We use it in /starlib/xlsx/xlsx.go and /dataset/dsio/xlsx.go, specifically the Rows.Columns() func.

function signature in the release version of 360EntSecGroup-Skylar/excelize:
func (rows *Rows) Columns() []string

function signature at head:
func (rows *Rows) Columns() ([]string, error)

Our code assumes the function signature at head (which was merged 11 days ago), but when you go get or run make update-qri-deps, go will pull the release version. This won't matter once a new version of excelize is released, and it won't matter to anyone who is not compiling Qri, but I wanted to note the trouble I ran into!

[ramfox]

Looks good :)

[b5]

@ramfox your issue with xlsx is related to #716, and further proof that we need go modules real bad. I've opened #726 to get us going on a better fix for the problem you ran into