Ensure that all named colors are predictably retrievable

[ozan]

While I can understand why the same hex color was added under multiple names, this has the unpredictable result that calling toName on a color constructed with a name returns a different name:

tinycolor('aqua').toName()  // -> 'cyan'

This happens for ten named colors right now. Nine of these are due to duplicate names for the same hex value (fixed in dd1b8fe) and one is due to the fact that "rebeccapurple" was added with a six character hex but is looked up with a three character hex (fixed in 47f0bd8).

I had a look and couldn't see a preferred deprecation strategy in this project, so I just removed the offending colors to demonstrate the point, and can modify this PR to follow a deprecation strategy if needed.

[bgrins]

Rather than removing the colors we could modify toName to check if the original input is part of the names set. What do you think?

We could pull the existing replace(trimLeft,'').replace(trimRight, '').toLowerCase() logic out into a normalizeStringInput function or similar, and then do something like:

var stringInput = normalizeStringInput(this._originalInput);
if (stringInput && names[stringInput]) {
  return stringInput;
}

[ozan]

Ha yes that's probably a better approach than removing the colors.

[bgrins]

@ozan mind updating the PR (or filing a new one) for that?