pixel_type more explicit and extended

[godber]

I have extended pixel_type to include more types and to be more
explicit. The handling of floats is not yet done. It is also not
yet clear to me why an assert wasn't working for me. I think the values
were equivalent, just not represented the same.

This isn't ready to be merged yet, I've just pushed it for review: @wtolson

I am still trying to figure out how to express IEEE_REAL and PC_REAL in numpy.

refs #16

[godber]

Actually, if I take the resulting img.data from the HiRISE PC_REAL example and do img.data.newbyteorder('<') it looks right.

Also, it would probably be more succinct if I used the <f4 or >i2 notation for creating these. I don't understand that notation yet, so I will have to look into it.

[godber]

:( broken, shame felt, looks like I need to ensure sample_bytes is an int.

[godber]

I like how this has worked out.

This notebook kind of indicates the status
http://nbviewer.ipython.org/urls/gist.githubusercontent.com/godber/2530f95e2986655ecaac/raw/Test_All.ipynb

Here are the data products in a json file:
https://gist.githubusercontent.com/godber/34a7639cfc457150f22c/raw/4d1e3745f8e68a0d7b6106cf5cd2fba4102fb074/mission_data.json

I think I understand most of the failures here:

• Mastcam PDS products fail because of JPEG compression
• ESP_030168_1755_BG12_0.IMG fails because RECORD_BYTES isn't present. The parse_pointer method should be called differently to support this type. Handle pointer offsets that are expressed in bytes #21
• W1782844276_1.LBL will be handled by Handle LINE_SUFFIX and PREFIX data defined in external tables. #18
• RA_090929123307_PIX3_LIN.LBL no idea what this should look like

Not sure whats up with M1166071628ME.IMG.