Implement sass value operations and stringification

[mgreter]

Brings recently added functions for sass values from libsass C-API to node-sass. I guess it was partly due to missing libsass documentation, which was not updated in this regard (until some time earlier this day). Was a pitty that so far only perl-libsass implemented them and it was pretty straight forward to do so for node.js (very first time that I'm really doing something in node.js, beside being a day time js programmer).

Each and every sass value type get these methods via their protoype:

// execute operator on this and rhs
// operator: string identifier for operator
// [eq|gt|lt|or|and|neq|gte|lte|add|sub|mul|div|mod]
// rhs: right hand side value for operation
// return a new sass value (bool, string, etc)
var result = val.operation(operator, rhs);

// overloaded operator
var string = val.toString();

I also hope that this may bring some value back to libsass in general, as these functions expose quite a low level API, as concatenation or equality tests are the same as libsass uses internally. One big open question is still how we gonna test the API on the libsass side. So far we rely on our implementors to add some unit test. So we pretty much need a full featured test suite for sass operation and stringification. Altough I would much better like to have this directly in libsass (so it is run with our CI), but node-sass seems a good place to get something started. Specially since @chriseppstein seems to use it himself. And I consider him the authority to know how these operations should behave. I am for the most part just reverse engineering the existing 😄 Anyway, that would be one long-term goal here.

On the other hand they are also usefull for end users. Unfortunately it looks that v8 has decided to not support any kind of custom operator overloading. The closest thing I could find in this direction is a patch that looks to come from QT. Not a compelling sign, and all other sources point to "no, can't do". So the next best thing is probably to use methods (I mean the language even has java in its name, so ...).

I figured this could go two ways. Either have multiple methods for each operation: a bit more well defined but cluttering the prototype. Use only one method with switch argument: the string argument feels a bit quirky but works and also adds some versatility (can easly be stored/passed). The first idea could also be implemented around the second approach.

Also not 100% sure if a node.js library should overload toString. But I don't see why we shouldn't do that for our own custom objects, until you need it for some ubique equality test. Didn't bother to add any documentation up to this point as I first want to gather some feedback!

[mgreter]

Tried to stay as close as possible to other error messages.
But I just couldn't help wondering, why should and not must?
To me it looks like a very strict constraint one should meet 😉

[mgreter]

@saper maybe I missed the point, but it was about the input to unwrap. I want to put in 2 and get a sass number 2 with no unit. unwrap(2) => SassNumber(2, "") (info[0] beeing a native js number).
I meant upgrade in the sense to upgrade native types to sass values.
And as I said: "Or is there another utility function that does just that?"