feat(ngModel): bind to getters/setters

Currently, you might do this if you want to bind to getters/setters:

> controller

```javascript
// ...
$scope.watch(function () {
  return myModel.getterSetter();
}, function (newValue) {
  $scope.someProp = newValue;
});

$scope.watch('someProp', function (newValue) {
  myModel.getterSetter(newValue);
});
// ...
```

> template

```html
<input ng-model="someProp">
```

The implementation in this PR changes the semantics of `ngModel` in the following ways:

If the expression bound to `ngModel` resolves to a function, the function is invoked to get the current value to be expressed in the DOM. When the binding changes, if the expression bound to `ngModel` resolves to a function (at that time) the function is invoked with the new value.

This means instead, you could do this:

> controller

```javascript
// ...
$scope.myModel = myModel;
// ...
```

> template

```html
<input ng-model="myModel.getterSetter">
```

I like that to end developers, this feels like "uniform access" for common cases. I don't like that this means there's a difference in semantics between `ngModel` and expressions elsewhere in Angular.

This would be a breaking change, but I don't think that this would affect any legitimate use cases. The only case I can think of is if hypothetically, you bind to some property that's originally a function, overwriting it with a string. I can't think of any good reason to write controller code like that.

@IgorMinar suggested a different syntax so that the difference in semantics is obvious. Something like:

```html
<input ng-model="myModel.getterSetter()">
```

I like that this makes the semantics obvious. I don't like that this still violates the "uniform access principle."

Closes #768
I would rewrite this to "to an element that has an ngModel attached to it, (most likely an input), or to a <form>, which will enable getters for all inputs in it." + formatting

Reason: Inputs are not the only elements that can have ng-model, and adding it to forms is still a secondary use case (and not everyone who uses getters is aware of the debounce stuff etc.)