Work Item List Pagination links does not contain valid QueryParameters

[aslakknutsen]

The URLs provided by the Work Item List use ',' as Query Parameter separator instead of '&'

Expected behavior

links":{
  "first":"/api/workitems.2?page[offset]=0&page[limit]=0",
  "last":"/api/workitems.2?page[offset]=132067&page[limit]=1",
  "prev":"/api/workitems.2?page[offset]=132067&page[limit]=1"
}

Actual behavior

links":{
  "first":"/api/workitems.2?page[offset]=0,page[limit]=0",
  "last":"/api/workitems.2?page[offset]=132067,page[limit]=1",
  "prev":"/api/workitems.2?page[offset]=132067,page[limit]=1"
}

Steps to reproduce the problem

Invoke the service.

The 'quick' fix is to just replace ',' with '&', but due to Go JSON encoders built in HTMLEscape it converts all < > & to e.g. \u0026. While fully spec compliant for JSON strings, JS does not seem to understand much of it without a manual string replace.

In Go 1.6 I've only managed to 'fix' this by a rather elaborate workaround:

• Make links in goa defined as d.Any (interface{})
• Make all links Required (to avoid a pointer to an interface{} being generated)
• Make a custom string type with a custom MarshalJSON function
• Change the JSON encoder used from Go to the one defined in Goa

The downside of this approach, besides the elaborate swing dance, is that when Attributes are Required in Goa no omitempty JSON tag is generated for it, which means that 'nil' links will be serialized as "next": null. Not the end of the world but...

The reason for the HTMLEscape is due to some old browsers didn't decode the JSON properly when used in tags. While probably a valid reason, I don't see it as much of a reasonable usecase for us today.

The cleaner fix is to update to Go 1.7 where the JSON Encoder API now supports "func (enc *Encoder) SetEscapeHTML(on bool)". This would still require registration of custom encoders to override the default, but that's a minor task.

Depends on #426
Related #329