Rename a few functions, create Libcfitsio submodule

[kbarbary]

This PR consists of two commits:

Renames

The first commit renames some functions in the high-level API according to the style guide:

• readkey -> read_key
• readheader -> read_header
• getcomment -> get_comment
• setcomment! -> set_comment!

It's my fault that these functions weren't named this way to begin with. I was trying to mimic naming conventions in Base (e.g., haskey(d)), not realizing that the style guide is a "do as we say, not as we do" sort of thing.

It also deprecates the hdu[i:j, k:l] syntax for reading a subset of an image HDU in favor of the more explicit read(hdu, i:j, k:l). I really like this change as it makes all read and writes from the file explicit, making the whole API more consistent.

There are deprecation warnings for all these changes.

Libcfitsio submodule

The second commit moves all of the low-level interface into a Libcfitsio submodule, as proposed in #27. This would require users of the low-level fits_* functions to do using FITSIO.Libcfitsio rather than just using FITSIO. Otherwise all low-level code would remain the same. What do users of the low-level API think about this? cc @emmt @ziotom78

There are not deprecation warnings for this change, but users only need to replace using FITSIO with using FITSIO.Libcfitsio to comply with the change.

[ziotom78]

@kbarbary , thanks a lot for this PR, as I said before I find your idea of having a low-level submodule perfect. No objections about changing using FITSIO into using FITSIO.Libcfitsio, it's a minor change that's easy to remember.

[emmt]

What you propose is fine for me. I will modify OIFITS.jl to reflect these as soon as possible. Do you plan to make a new release of FITSIO.jl?

[kbarbary]

@emmt Yes, after this is merged would be a good time for a new release.