Support alternative layouts in memory

This allows one to define new concrete types that can match the memory layout expected by C libraries. I don't believe it interferes in any way with the fundamental colorimetry purpose of Color.jl. Other than inserting a layer of abstraction, I'm not adding any new types; I'm just trying to make it possible for other packages to define them and get the goodness of the conversion functions in this package.

Cairo, for example, encodes color as a Uint32. On a little-endian machine, this is in the order `argb` going from most-to-least significant byte (concretely, the rule is `a<<24 | r<<16 | g<<8 | b`), corresponding to an immutable that might look like this:
```
immutable BGRA
    b::Ufixed8
    g::Ufixed8
    r::Ufixed8
    alpha::Ufixed8
end
```
You can represent this as an `AlphaColorValue{BGR{Ufixed8}, Ufixed8}` given a suitable definition of `BGR`.

What's interesting is that all the colorimetry formulas remain the same, regardless of layout. **All of the AbstractRGB types are to be initialized in order `(r,g,b)`, and then the type constructor is responsible for swapping the order as necessary.** This preserves the "meaning" of the inputs, regardless of internal representation.

This PR does include some examples of using this functionality in the new `test/layout.jl` file, but the types it defines for testing purposes are not actually in the Color module.

Also in the course of thinking about memory layout, I realized that my formerly-named RGBA32 really should have been called ARGB32. So I renamed it and inserted a couple of deprecations.

CC @SimonDanisch.