docs(tutorial): move bower_components into app folder
chore(travis): run protractor tests with ff28

FirefoxDriver seems to have an issue with FF29 which is breaking a test case, and causing false negatives.

There is an issue opened on protractor regarding this at https://github.com/angular/protractor/issues/784

Closes #7369
docs(minErr): small grammar fix for $compileMinErr ctreq

Closes #7365
docs($rootScope): use unshift to add items to the array at the beginning

Closes #7364
docs(NgMessages): fix up links and headings
docs(directive): fix misspelled HTML class for an alert

Muchas gracias

Closes #7381
docs(Scope): fix typo in a link

Closes #7389
docs(ngCookies): correct arguments in $cookieStore example

Closes #7390
docs(dateFilter): correct example for date 'fullDate filter'

The equivalent expanded example for 'fullDate' is given as 'EEEE, MMMM d,y'
whereas it should be 'EEEE, MMMM d, y'. With added whitespace.

Closes #7350
docs(CONTRIBUTING.md): anchor fix

"Follow our Coding Rules" should link to "#rules" and not "#coding-rules"

Closes #7349
docs(CONTRIBUTING.md): anachor fix

Closes #7294
docs(CONTRIBUTING.md): grammar and link fixes

Fix dev-doc link, grammatical error.

Closes #7275
fix(ngSwitch): properly support case labels with different numbers of transclude fns

Due to a regression introduced several releases ago, the ability for multiple transclude functions
to work correctly changed, as they would break if different case labels had different numbers of
transclude functions.

This CL corrects this by not assuming that previous elements and scope count have the same length.

Fixes #7372
Closes #7373
refactor(inputSpec): move call to `$digest` into `compileInput` helper

It is reasonable to expect a digest to occur between an input element
compiling and the first user interaction.  Rather than add digests to
each test this change moves it into the `compileInput` helper function.
refactor(ngModelOptions): move debounce and updateOn logic into NgModelController

Move responsibility for pending and debouncing model updates into `NgModelController`.
Now input directives are only responsible for capturing changes to the input element's
value and then calling `$setViewValue` with the new value.

Calls to `$setViewValue(value)` change the `$viewValue` property but these changes are
not committed to the `$modelValue` until an `updateOn` trigger occurs (and any related
`debounce` has resolved).

The `$$lastCommittedViewValue` is now stored when `$setViewValue(value)` updates
the `$viewValue`, which allows the view to be "reset" by calling `$rollbackViewValue()`.

The new `$commitViewValue()` method allows developers to force the `$viewValue` to be
committed through to the `$modelValue` immediately, ignoring `updateOn` triggers and
`debounce` delays.

BREAKING CHANGE:

This commit changes the API on `NgModelController`, both semantically and
in terms of adding and renaming methods.

* `$setViewValue(value)` -
This method still changes the `$viewValue` but does not immediately commit this
change through to the `$modelValue` as it did previously.
Now the value is committed only when a trigger specified in an associated
`ngModelOptions` directive occurs. If `ngModelOptions` also has a `debounce` delay
specified for the trigger then the change will also be debounced before being
committed.
In most cases this should not have a significant impact on how `NgModelController`
is used: If `updateOn` includes `default` then `$setViewValue` will trigger
a (potentially debounced) commit immediately.
* `$cancelUpdate()` - is renamed to `$rollbackViewValue()` and has the same meaning,
which is to revert the current `$viewValue` back to the `$lastCommittedViewValue`,
to cancel any pending debounced updates and to re-render the input.

To migrate code that used `$cancelUpdate()` follow the example below:

Before:

```
  $scope.resetWithCancel = function (e) {
    if (e.keyCode == 27) {
      $scope.myForm.myInput1.$cancelUpdate();
      $scope.myValue = '';
    }
  };
```

After:

```
  $scope.resetWithCancel = function (e) {
    if (e.keyCode == 27) {
      $scope.myForm.myInput1.$rollbackViewValue();
      $scope.myValue = '';
    }
  }
```
feat(FormController): commit `$viewValue` of all child controls when form is submitted

Use the new `NgModelController.$commitViewValue()` method to commit the
`$viewValue` on all the child controls (including nested `ngForm`s) when the form
receives the `submit` event. This will happen immediately, overriding any
`updateOn` and `debounce` settings from `ngModelOptions`.

If you wish to access the committed `$modelValue`s then you can use the `ngSubmit`
directive to provide a handler.  Don't use `ngClick` on the submit button, as this
handler would be called before the pending `$viewValue`s have been committed.

Closes #7017
fix($compile): set $isolateScope correctly for sync template directives

All isolated scope directives that do not have `templateUrl` were marked
as `$isolateScopeNoTemplate` even if they did have a `template` attribute.

This caused `jqLite#scope()` to return the wrong value for child elements
within the directive's template.

Closes #6942
chore(Gruntfile): remember to minify ngMessages
docs(changelog): release notes for 1.3.0-beta.8 accidental-haiku
refactor(jqLite): stop patching individual jQuery methods

Currently Angular monkey-patches a few jQuery methods that remove elements
from the DOM. Since methods like .remove() have multiple signatures
that can change what's actually removed, Angular needs to carefully
repeat them in its patching or it can break apps using jQuery correctly.
Such a strategy is also not future-safe.

Instead of patching individual methods on the prototype, it's better to
hook into jQuery.cleanData and trigger custom events there. This should be
safe as e.g. jQuery UI needs it and uses it. It'll also be future-safe.

The only drawback is that $destroy is no longer triggered when using $detach
but:

  1. Angular doesn't use this method, jqLite doesn't implement it.
  2. Detached elements can be re-attached keeping all their events & data
     so it makes sense that $destroy is not triggered on them.
  3. The approach from this commit is so much safer that any issues with
     .detach() working differently are outweighed by the robustness of the code.

BREAKING CHANGE: the $destroy event is no longer triggered when using the
jQuery detach() method. If you want to destroy Angular data attached to the
element, use remove().