`.hex()` silently drops alpha info. #243

Yes, I have searched the closed issues and read what's there.

Problem: Color.prototype.hex() breaks the principle of least surprise.

The behavior is never documented (not even in a test).

It's inconsistent with the existing behavior of .rgb().toString(), .hsl.toString() et. al.
All those methods intelligently switch between rgb and rgba, hsl and hsla etc. when appropriate. (Note: Currently the only way to force a "rgb()" string is to first run .alpha(1))

I see a few ways to mend this, and I'm willing to make a PR if you're willing to accept any of them:

1) Documentation:

1. Add clearly worded note in the README warning of this behavior.
2. Add a test that tests for this behavior. 2) Add a lossless .toHex() method that switches between .hex() and .hexa()
3. Add tests for the new method. 3) Make .hex() more similar to .rgb().string():
4. Change .hex() to automatically emit the alpha channel when valpha < 1.
5. Update the tests for .hex()
6. Either deprecate .hexa() or add a new lossy .hex6() method.

Methods 1 and 2 easily go together.

Method 3 could qualify as a non-breaking change, as the current behaviour has never been tested or documented.