More consistent named color variables (#1595)

[seven-phases-max]

See #1595.

Summary of changes:

[1]. Color variable outputs a named color if this variable was defined with a named color.

[2]. Named color is NOT used after you apply any math operation or one of the color processing functions (even if the value itself is not changed):

@teal: teal;
1: @teal;             // -> teal
2: (@teal + 0);       // -> #008080
3: (@teal / 1);       // -> #008080
4: spin(@teal, 0);    // -> #008080

[3]. Fixed the following inconsistency (#1382):

1: red;               // -> red
2: /* oops */ red;    // -> #ff0000
3: red                // -> #ff0000

Now all three are red.

[4]. This patch does NOT change the following:

1: (wheat + #111);    // Error

[5]. Named to numeric color conversion. color function now also accepts unquoted args and always outputs a numeric value:

@plum: plum;
1: color(@plum);      // -> #dda0dd
2: color('#dda0dd');  // -> #dda0dd
3: color('plum');     // -> #dda0dd
4: color(#dda0dd);    // -> #dda0dd
5: color(plum);       // -> #dda0dd

[6]. color function now performs more strict "3/6-digit" conversion. This fixes the following inconsistencies:

1: color('#123x');     // -> #112233NaN
2: color('#010y');     // -> #001100NaN
3: color('#01020z');   // -> #010200
4: color('#12345');    // -> #1122334455
5: color('#123 etc.'); // -> #112233NaNeeNaNccNaN

Now such cases result in a error.

[7]. Added support for case-insensitive colour keywords (follows #1803).

[lukeapage]

okay, I think it looks good. since it is a breaking change I would like other peoples opinion before it is merged into a next major or minor release. Also we will need to add 2 functions to force to a keyword or force to a color code in order that people can get around the breaking change if they are using a color variable to for instance append to an imported url (which some people do, I've seen in issues).

[seven-phases-max]

Yes, I think we need to give it a time for more opinions to appear. Also I'm especially concerning about compatibility with --compress option, it looks like I definitely should modify this somehow.

[lukeapage]

I'm going to pull this into 1.6, along with your other bigger changes. For now I'm pullijng smaller, safer bug fixes and things for a 1.5.1 release. but thanks very much not just for this but other changes...

[seven-phases-max]

Thanks, I think I will make some minor improvements before 1.6 (performance optimization + explicit functions for conversion maybe... not sure yet)

[seven-phases-max]

I'm going to pull this into 1.6

It's strange. I did not actually forget about this PR but for some reason I thought we decided to pospone this until 2.x or something like this... I don't know why... But considering changes in #1803 I think this one is better to come earlier...

[lukeapage]

pulled into the 2.0.0 branch

[scottgit]

I just want to clarify that the plan for these changes in the 2.0.0 branch will allow for this example of what I desire to be able to do:

@red: #f20000;

.mixin(@colorName) {
   color: @@colorName;
}

.test {
  .mixin(red);
}

I'm defining a new "red" value through @red, but I want to use the keyword red rather than expect the user to have to pass "red" (as a string) and then escape it, or pass an escaped ~"red" themselves. Basically, I just want to be sure that both parameters and set variables are set up such that...
1: @teal; // -> teal
...whether the variable is set as a parameter or as global or local variable otherwise, and therefore can be retrieved as the keyword value for doing something like the above.

[seven-phases-max]

@scottgit I've tested it and no, unfortunately your example fails with this PR (internally @@colorName still points to @undefined because @colorName is still of color type and not a keyword :( Well, this will be not so difficult to fix actually so I hope I will submit a patch for this (when I'll be less limited in time as I am for the moment).

P.S. The simplest fix would be just to rename this variable to value but more tests/analysis are needed to make sure it won't break something else...