Allow functions to be specified for scale grid line options

[etimberg]

Builds off of #6697 to add function options for grid line styling. I couldn't support a function for the borderDash option because the type is an array and so indexing would go badly.

I added a sample, the image of which is shown below

[benmccann]

Just FYI, the build is failing

[etimberg]

Looks like I have a lint error in the HTML sample

[kurkle]

Might be a stupid idea, but should we consider making grid lines Elements?

[benmccann]

Might be a stupid idea, but should we consider making grid lines Elements?

I'm trying to do an Element refactoring at the moment, so would prefer to hold off on anything along those lines to avoid complicating it. Hope to have something to share shortly!

[kurkle]

Note: build is failing

[etimberg]

Thanks @kurkle. Looks like I rebased something badly

[benmccann]

The docs don't specify what the function context is which might be useful since it's not the normal context that's passed in.

I couldn't support a function for the borderDash option because the type is an array and so indexing would go badly.

Could you just make this one scriptable and not indexable? (though even with indexing it's not quite clear to me what would be wrong. the user could theoretically pass an array of arrays)

[kurkle]

@benmccann resolve will think the normal single value is indexed, because it is an array. So would need some changes to resolve or how borderDash is configured.

Not quite in the scope of this PR:
I think it would actually make sense to have a border option object, that can be indexable / scriptable and having color, dash, width, dashOffset properties in that.

Another thing I was thinking about is hover, point etc, rather than prefixing the key, we could include a object instead:

left cfg = {
  type: 'line',
  data: {
    datasets: [{
      border: {
        width: 2
      },
      point: {
        backgroundColor: 'red'
      },
      data: [1, 2, 3]
}

This would be easier in some aspects. Could be also faster in some cases (define all border properties in a single function call vs 4 different calls when scriptable).
Could also be a nightmare to memory usage / non scripted config resolution, not quite sure.

[benmccann]

@etimberg looks like this one will need to be rebased

[benmccann]

Lgtm. The only comment I had was that the docs don't specify what the function context is. I think that might be useful to include since it's not the normal scriptable options context that's passed in.

[etimberg]

@benmccann I added a note on the context format