support colliding CSS filter effects functions

[benesch]

@hcatlin this a rebased #467.

I wasn't able to repro your alpha test failures—is alpha even tested?—but this passes ./script/spec successfully for me!

---

CSS filter effects 0 define several functions (invert, grayscale,
opacity, saturation) that collide with the names of built-in Sass
functions. Overload these functions with a no-op when the filter effects
function signature is discovered. This is compatible with Ruby Sass.

For example, calling invert with a color will return an inverted color
as before:

color: invert(#333) => color: #cccccc

But calling invert with a percentage will pass through the function
call unharmed.

filter: invert(30%) => filter: invert(30%)
filter: invert(.03) => filter: invert(.03)

Fixes #151.

[coveralls]

Coverage decreased (-0.11%) when pulling 8a866f3 on benesch:filter-effects-functions into 3a404a8 on sass:master.

[HamptonMakes]

I didn't see any tests for this, so @malrase wrote some up. It is here: https://github.com/malrase/sass-spec/blob/issue_151/spec/libsass-todo-issues/issue_151/input.scss

WE ARE SO CLOSE... but the tests that we wrote fail.

With Sass 3.4, when you do "saturate(red)" with only one variable, it doesn't error, it returns "saturate(red)". Right now, as written, it breaks.

So close! Come on! Help us finish this one up!

[malrase]

Here's the saturate test case as a gist:
http://sassmeister.com/gist/b906aa9a86d31f921bf2

If Sass sees one variable, it just ignores the saturate() and exports it directly into the CSS.

If there's two variables, it does the colour maths on saturate().

[malrase]

I added a new test to the sass-spec (PR: sass/sass-spec#66) to cover the weird saturate() case.

[benesch]

Ah, okay. I added some tests of my own for this way back when (sass/sass-spec#35), but looks like I missed the tricky saturate case. I'm on it!

[coveralls]

Coverage decreased (-0.11%) when pulling 46769e9 on benesch:filter-effects-functions into 3a404a8 on sass:master.

[benesch]

Well, that was tricky.

Turns out the saturate overload as I originally wrote was okay, though it didn't quite agree with Ruby Sass. Since CSS3 filter functions can only take numbers as arguments, I was checking whether the first argument was a number. So

saturate(red)

was getting rejected as a CSS3 filter function overload, since red isn't a valid value for a CSS filter function, whereas

saturate(10)

would get accepted as a CSS3 filter function overload, since 10 is valid there.

Anyway, for compliance with Sass, I've updated the overload to naively check for the existence of the second $amount argument, and assume that the user intends the filter function overload if s/he only provides one argument.

Then just a couple minor output formatting modifications (see commit messages) to achieve parity with Sass.

[HamptonMakes]

Alright, this looks good to me now.