[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.extedn({
    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;
  });
```