Ember.computed.literal, Ember.computedMacro

Note this depends on #4182 so that one needs to be good to merge before merging this.

[FEATURE composable-computed-properties] add `literal`, `computedMacro`.

Add two functions, `Ember.computed.literal` and `Ember.computedMacro`, for
helping a) build composable computed properties and b) build cp macros that
are indifferent to their arguments' statuses as either literals or paths.

Consider the current version of `Ember.computed.match`:

```js
 includesWat: match('stringProperty', /wat/i)
```

Why is the first argument a path but the second argument a literal?  The
basic functionality of `match` should work with both literal regular
expressions and ones that are properties.

With this commit it is now possible to do the following:

```js
 var p = Ember.computed.alias,     // "property"
     match = Ember.computed.match;

  var obj = Ember.Object.extend({
   includesPattern: match(p('stringProperty'), p('patternProperty'))
 }).create({
   stringProperty: 'Behind the WAT!',
   patternProperty: /wat/i
 });
```

Similarly, the literal/property semantics of macros like `gte` can be
reversed:

```js
 var gte = Ember.computed.gte,
     l = Ember.computd.literal,
     p = Ember.computed.alias;

  var obj = Ember.computed.extend({
   isGTEBound: gte(l(200), p('bound'))
 }).create({
   bound: 150
 });
```

This support is added for the basic, non-reduceComputed macros in
`Ember.computed`.

Users can easily create similarly literal/property agnostic macros via
`Ember.computedMacro`.

Here is an implementation of ember-cpm's `among`:

```js
 among = Ember.computedMacro(function (testValue) {
   for (var i=1; i<arguments.length; ++i) {
     if (testValue === arguments[i]) {
       return true;
     }
   }

    return false;
 });
```