Add method to invert a ColorScheme (inverse of get)

[NHDaly]

Fixes #10.

This PR is to add a method which is the inverse of get(cscheme, x).

For now, I've just copied over invert from NHDaly/ColorSchemesInvert.jl. For more details see NHDaly/ColorSchemesInvert.jl/.../README.ipynb.

invert places a color within a colorscheme, by converting the color to
a value representing its position on the colorscheme's axis.

Put another way, it returns the value in the domain for which its
colorscheme value most closely matches the provided color.

[NHDaly]

This is still a work in progress. I'm not exactly sure how the method should work, but this is a good start. It does what I think it should, although doesn't behave quite like I expected. See:
https://github.com/NHDaly/ColorSchemesInvert.jl/blob/4e50015b681679d45cf4f7ddf2d929cc63e67849/test/runtests.jl#L41

I'd love to talk it through some with folks! :)

[cormullion]

The style is to use lowercase (“squishcase”, juliacase) rather than camelCase, so this should be convert_to_scheme or something better...

[cormullion]

You could move the export line from line 5 to line 116.

[cormullion]

I'm wondering whether an alternative to invert would be getinverse, because it doesn't invert some object, rather it 'gets' a value...

[NHDaly]

You could move the export line from line 5 to line 116.

Oh sure, can do. Thanks. I didn't notice it way down there. Is there no convention on putting the exports at the top?

[NHDaly]

I'm wondering whether an alternative to invert would be getinverse, because it doesn't invert some object, rather it 'gets' a value...

Yeah I think that's better. I can't really think of anything better than that. Thanks! I'll make that change too.

[NHDaly]

The style is to use lowercase (“squishcase”, juliacase) rather than camelCase, so this should be convert_to_scheme or something better...

Okay I've changed it to convert_to_scheme for now. But actually, I'm not even sure it's worth including in this PR at all.. It was mostly just something fun that occured to me after implementing getinverse. I think right now it has some surprising results due to a surprising definition of "similarity" between colors.

getinverse is very useful for determing where in a given ColorScheme a color lies -- if it's actually from that colorscheme, but it has unexpected effects when converting between color schemes. For example, here, one would expect the black-to-white scale to map 1:1 directly to the black-to-red, but this is not actually the case:

So anyway, maybe we just remove this function for now?

[cormullion]

Let’s merge this, make a release, and take it for a spin... If it proves problematic we can either document its problems or remove it; if it works we can improve the docs... it will all need extensive changes in a few months anyway!