BetterColorChange

In general, the lightening/darkening algorithm in BTTV does change the hue of a color, particularly when one of the RGB components is FF, another is 00, and the third is neither (for example, a deep purple, with small nonzero R, G=0, and B=FF, will be hue-shifted toward magenta); this changed algorithm converts to HSL as an intermediate step, changes luminosity directly, then re-converts to RGB, which is slower and still subject to round-off error but avoids the bias toward the secondaries (when lightening) or primaries (when darkening) of Sitepoint's naïve method.

I changed the iterative lightening algorithm to avoid fixed points: Instead of lightening by 20%, I inverted luminosity, darkened by 80%, then inverted again, so that even Black, Blue, Red, and Magenta would become light enough without the need for special-case logic.

I then further changed it to use factors of 10% in both directions, because the way I had it, Black was sent to #C2C2C2 and White was sent to #444444; I also found out I had forgotten to normalize RGB back to [0,255] in the achromatic code-path in hslToRGB and that's why White became so dark.
merge upstream changes
Merge remote-tracking branch 'upstream/master'
Merge branch 'master' of https://github.com/lewisje/BetterTTV into lewisje-master

Conflicts:
	package.json
	src/main.js