Fix deprecation warnings

[KristofferC]

Wrapping ALL of PGFPlots is likely far away, this provides an escape hatch to inject arbitrary options into an axis:

This PR also fixes the deprecation warnings for 0.6.

[coveralls]

Changes Unknown when pulling 1955e5e on KristofferC:kc/customOptions into ** on sisl:master**.

[coveralls]

Changes Unknown when pulling e1a8f7e on KristofferC:kc/customOptions into ** on sisl:master**.

[coveralls]

Changes Unknown when pulling e1a8f7e on KristofferC:kc/customOptions into ** on sisl:master**.

[KristofferC]

Hmm, I wonder if this is the best interface. Sometimes you don't want to give a key value pair but simply a string (like xmajorgrids). Perhaps the dict should just be a Vector{String} and one would have to pass things like customOptions = ["cycle list name = exotic"]

[KristofferC]

It could perhaps also be nice to be able to give a customOptions to the different plot objects (in the same way as is done for the axis here).

[tawheeler]

Thank you for writing this!
One thing that has bugged me with PGFPlots is that it doesn't store the data in a data structure resembling the hierarchical property trees that LaTeX code is written in. We currently typically use strings like style="width=8cm, black, opacity=0.5, legend style={at={(0.03,0.97)}}" to represent what is really more like a json object:

{
    "width": "8cm",
    "color": "black",
    "opacity": 0.5,
    "legend style": {
        "at": "{(0.3,0.97)}",
    }
}

There are some differences - "black" for instance can be passed in as a value without having an associated key name.
It would be nice if PGFPlots was changed to convert passed in parameters to such a form that could be queried, etc. Right now it isn't easy to tell if a particular value has been or has not been set.

Definitely want to hear what @mykelk has to say.

[mykelk]

Arbitrary options can be passed to an axis through the style keyword argument. I think the only functionality this adds is converting a Dict to a string, but I think we can handle that by dispatching on the type passed to style. Right?

It might feel a little strange passing these options in as a string, but I put that support in initially so that we can do anything the latex package supports. One thing that I was thinking of doing was allowing varargs and then converting those key-value pairs. I turns out that Julia's version of varargs even supports non-assignments, like the "black" option that @tawheeler mentions above.

I'd like to know your thoughts. And thank you for your contribution! We'll want to settle these question before merging. (And thanks for the fixes for 0.6.)

[KristofferC]

I didn't think about passing it through style, that makes this PR redundant. I can split out the deprecation commits to a separate PR.

[mykelk]

Sounds good. It would be great to get those deprecation commits in. Thanks!

[KristofferC]

I've changed this to only fix deprecation warnings in code and notebook

[coveralls]

Changes Unknown when pulling 4eecb93 on KristofferC:kc/customOptions into ** on sisl:master**.

[tawheeler]

Btw further discussion should be on #69

[mykelk]

@tawheeler I'm okay with merging if you are. Go for it if you're good with it.

[tawheeler]

Thank you!