jq: bump up gojq, better query parse error, handle halt error gracefully

[itchyny]

The error of invalid --jq query is difficult to know what's wrong with the query. As a gojq library maintainer, I was wondering whether the library should return pretty error or not, but since the query input is given by library user, returning an error with offset is enough as a library, just like json.SyntaxError. In the release v0.12.15, I decided to export gojq.ParseError, which has the offset position in the query. This PR improves the parsing error message to report that position in fancy style. It also improves handling of halt errors.

 $ gh api /user --jq '[1,2,3,,4,5]'    
unexpected token ","

 $ bin/gh api /user --jq '[1,2,3,,4,5]'
failed to parse jq expression (line 1, column 8)
    [1,2,3,,4,5]
           ^  unexpected token ","

[williammartin]

This is a great contribution @itchyny. Thanks a lot for maintaining gojq and helping us use it better!

Here's a comparison between current release, and this PR:

➜  ~ gh api /user --jq '. | [1,,3]'
unexpected token ","

failed to parse jq expression (line 1, column 8)
    . | [1,,3]
           ^  unexpected token ","

That's really nice!

[williammartin]

For anyone else wondering what this is about, from the gojq docs:

In any case, it is recommended to stop the iteration on gojq.HaltError, which is emitted by halt and halt_error functions, although these functions are rarely used. The error implements gojq.ValueError, and if the error value is nil, stop the iteration without handling the error. Technically speaking, we can fix the iterator to terminate on the halting error, but it does not terminate at the moment. The halt function in jq not only stops the iteration, but also terminates the command execution, even if there are still input values. So, gojq leaves it up to the library user how to handle the halting error.

This is handing the case when the jq expression contains halt (exit with no error), which previously we wouldn't have respected.