Optimized header reading

[Razican]

This uses quick_xml for a much faster reading of the XML header. There is still room for improvement, and that's why I'm placing this as a draft PR.

This also changes the following:

• Created a new XISFile structure that contains the header, the data and the keywords of a XISF file together in one structure.
• No need to use String::from(""), String::new() is more clear
• Removed the unused lazy_static dependency
• Upgraded dependencies
• Added readme, repository and license metadata attributes in Cargo.toml, so that it can be published in crates.io
• Removed a couple of redundant clones
• Added a proper error message when an "unsupported XISF type" is found.
• Do not read the header as a string to memory, use a buffered I/O reader.
• Use an enumerated value for header types (#6)
• Use Box<[T]> and Box<str> instead of Vec<T> or String respectively, for better memory usage. (not 100% finished)
• Use "getters" and "setters" for structures, so that we can add methods that maybe do some math.

Improvements to be done:

• Remove all those unwrap() panics, and use a proper error handling with either anyhow or quick-error
• Do not store non-needed values in the header (we currently store the string representation and the parsed values)
• XISFData should be a generic structure on its type of content, in order not to have duplicated (and empty) lists.
• Try to use the new methods in the standard library for BE/LE convertions (if possible) instead of using the byteorder crate.
• Move tests to a different folder, to do integration tests
• Use iterators instead of slicing for better performance.

Note that there seems to be an ignored test with LZ4 compression.

[vrruiz]

Awesome! I'll take a look ASAP. Your list of improvents looks like a TODO list to me :)

I'll also take a look to the missing files.

[vrruiz]

The files are no longer missing. But there is a conflict now with src/xisfreader.rs

[Razican]

The conflict was due to "geometry" parsing being done in a different function. For now, I have just rebased the code, which should pass the tests. I will be reviewing how to simplify the code next.

[Razican]

I added some more optimizations. Most relevant is the inclusion of the XISFile structure, that contains the data, header and keywords in the same place, and the substitution of the type strings by an enumeration (#6).

I do have one question, though. When reading the geometry, it's prepared to read something like xxx:yyy:zzz. Is there a case where something like this could exist? uuu:vvv:xxx:yyy:zzz?

[vrruiz]

FITS, and thus XISF, is dynamic, so it can store basically anything. Specifically, XISF attribute is multidimensional: «geometry="dim1:...:dimN:channel-count"». However, PixInsight (the program) only works with regular images, so I cared most about common use and not corner cases.