Improve integration with code type definitions

[Enet4]

• specify memory representation in typedef::* (u16 or u8 depending on attribute)
• make utility methods in typedef::* take self by value (cheaper than by ref)
• make volume construction methods yield an InvalidCode error (instead of the less specific InvalidFormat)
• add NiftiError::InvalidCode variant
• add validating getters for these codes
• add methods for retrieving xyzt units with space-time separation

At first I considered modifying the attributes of NiftiHeader to contain these types immediately upon reading the header. With the repr directives, the header could still be packed without wasting memory and providing an extra layer of abstraction. However, I feel reluctant to make the entire reading process break just because of a single unknown code, which for the most part (datatype is an exception) are not critical. By keeping unvalidated codes, the library will give more flexibility to eventual file diagnostic tools.

[nilgoyette]

take self by value (cheaper than by ref)

Just to be sure, does calling a method on it consume the value? Or it's safe because it's a u8/u16 and they are defined as Copy objects? Probably the later.

Good job, lgtm.

[Enet4]

Just to be sure, does calling a method on it consume the value? Or it's safe because it's a u8/u16 and they are defined as Copy objects? Probably the later.

Yes, it is actually preferable for small Copy types to have consuming methods. It is perceived by the compiler as consuming a copy of the value, which is cheaper than making a reference to it (u8 vs &u8). In practice, usage doesn't change, but it's more idiomatic and leaves a bit more room for machine code optimization [citation_needed]. Primitive integer types in stdlib also follow this guideline (e.g. i16), and Clippy has a lint for this.