BUG: RLE codec was using big-endian ordering for 16-bit data.

The RLE segments start with the most significant byte and end with the
least significant.  On a little endian machine, this means starting with
the byte that is at the highest address.
Ensure that RLE codec works on big-endian machines, too.
Bump the version number to 0.5.0.

The major changes since 0.4.5 are as follows:
- Various cmake improvements, including CDash support
- The reader provides a vtkMedicalImageProperties object
- DICOM dictionary updated to the 2013 standard
- Resolution of private tags based on creator info
- niftitodicom supports RGB (for secondary capture only)
- native RLE codec (use DCMTK or GDCM for other codecs)
- API for vtkDICOMValue has been updated
- new vtkDICOMFile class allows utf8 paths

The API changes to vtkDICOMValue are as follows:
- GetNumberOfValues returns a size_t value, not unsigned int,
  and values with encapsulated data can now be > 4GB in size
- Methods that used to specify a range of values via a start
  and end pointer, now use a start pointer and a size