fix(directive-injector): wrong variable name in error thrown.

Add proper type annotation that would have caught the typo.

Closes #1397
feat(scripts): pick-pr

Closes #1394
fix(perf_api): updgrade the pkg minimum version to fix an analyzer error

fixes #1407

perf_api 0.0.8 contains an invalid const constructor which the type
checker ignored in dart 1.5.8 but throws on in 1.6. Using 0.0.9 fixes
this.

Closes #1408
feat(directive injector): DiCircularDependencyError -> _CircularDependencyError

And make _CircularDependencyError extends CircularDependencyError
so that catching CircularDependencyError catches any circular dep
error

Closes #1399
chore: update pubspec.lock
doc(pick-pr): Remove an obsolete comment
Revert "chore: update pubspec.lock"

This reverts commit a157cb2b6af63f3897692aa6a85e6ce0a15de948.

This commit did not pass Travis.
feat(directives): remove the @Controller directive

Completely remove the deprecated Controller directive.

Major update to the demos to use setRootContext (where applicable) and
to move to Components for the beefier demos (bouncing balls and form).

A temporary work around was required in demos (animation and todo)
so that rootContext have Map interface. The work arounds will disappear
after the context is set to the component.

Library changes were pulled out of the first commit in #1269.

Closes #1401
feat(scope): move domWrite and domRead from RootScope to Scope

Closes #1161

Closes #1341
chore(package.json): require newer karma-dart

This is needed for PR 1375.
fix: remove analyze warnings

Closes #1411
refactor: misc cleanup

Closes #1395
reflactor(parser): rename DynamicParser into Parser

Since there is only one implementation of the Parser interface, which is used for both dynamic and static deployments, calling it DynamicParser is misleading.

- Remove the Parser interface
- Rename rename DynamicParser into Parser
- Rename DynamicParserBackend into RuntimeParserBackend

Closes #1251
chore(travis): speed up dart2js unit tests

The dart2js jobs run times are dominated by slow Firefox runs.  In my
experiments, running multiple Firefox instances in parallel and sharding
the tests among them proved beneficial.

With this commit, the dart2js jobs take about 10m to run instead of 30m.
Compare these two recent Travis runs:
- 10m: <https://travis-ci.org/angular/angular.dart/builds/34415853>
  (this commit.)
- 30m: <https://travis-ci.org/angular/angular.dart/builds/34341163> (the
  commit just before this one.)

The following information is from earlier Travis runs.  Look at this
Travis run:
<https://travis-ci.org/angular/angular.dart/jobs/33159766>.  We can see
that the Firefox tests take 2m30s to run as opposed to the 25m [in a
regular run](https://travis-ci.org/angular/angular.dart/jobs/33152203).

There are actually 4 jobs running Firefox karma in parallel, each
running 1/4th of the normal tests.  The output is mingled but ok.

```text
Firefox 30.0.0 (Linux): Executed 409 of 409 SUCCESS (2 mins 16.855 secs / 2 mins 15.357 secs)
....................
..................................................
........................................
..................................................
Firefox 30.0.0 (Linux): Executed 410 of 410 SUCCESS (2 mins 14.153 secs / 2 mins 12.805 secs)
..................................................
........
Firefox 30.0.0 (Linux): Executed 408 of 408 SUCCESS (2 mins 34.253 secs / 2 mins 39.31 secs)
..................................................
...........
Firefox 30.0.0 (Linux): Executed 411 of 411 SUCCESS (2 mins 30.957 secs / 2 mins 29.93 secs)
```

This is how our traditional Firefox runs look:

```text
Firefox 30.0.0 (Linux): Executed 1565 of 1565 SUCCESS (25 mins 34.727 secs / 17 mins 13.582 secs)
```

Notes:
- The test output for the different shards are all intermingled.  This
  doesn't seem to be a big deal at the moment (they're all mostly just
  printing dots anyway) and we can certainly improve it later.  (GNU
  parallel instead of xargs would do this automatically but I think
  isn't installed and we don't have sudo.  We could roll our own.)
- Prereq: Commit 87279feb5096c3da29bc3014e8117d6d83cbf75a
chore(pubspec): pub get results to pubspec.lock
feat(urls): support relative CSS / template URLs in components

Example:
When defining a component called 'foo' in file
'/myproject/has/many/folders/foo.dart', prior to the change you would
do so thusly:
@Component(
   selector: 'foo',
   templateUrl: '/myproject/has/many/folders/foo.html',
   cssUrl: '/myproject/has/many/folders/foo.css'
)

The above is still valid, but now can also be defined rather more
succinctly as:
@Component(
   selector: 'foo',
   templateUrl: 'foo.html',
   cssUrl: 'foo.css'
)

A full table of what URLs will be changed/unchanged is below:
You Say:				Transformer replies:
'packages/foo/bar.html'			'packages/foo/bar.html'
'foo.html'				'packages/foo/bar.html'
'./foo.html'				'packages/foo/bar.html'
'/foo.html'				'/foo.html'
'http://google.com/foo.html'		'http://google.com/foo.html'

*Note  that as  shown any absolute paths you define will not be
bothered by the transformer, so if you have a templateUrl living at
<root>/foo.html, you can still reach it with '/foo.html'!

BREAKING CHANGE:

You must update relative paths to your templates and in ng-include's to
be relative to the component's library / ng-include'd file.

NOTE: This feature is defaulted to an "on" state.  To get back the old
behavior, you may disable this feature for your application.  This is
only to help you adjust to this change and will go away in a later
version.  Here's how you can get the old behavior:

```dart
module.bind(ResourceResolverConfig, toValue:
	new ResourceResolverConfig.useRelativeUrls(false));
```

*Testing*:
- e2e transformer tests can now be done on the sample application found
  in the test_transformers folder
fix(WTF): add back traceDetectWTF call in application start

Accidentally removed in previous commit.
chore(travis): custom merge pubspec.lock for g3v1x rebases

pubspec.lock changes will never really apply cleanly to g3v1x.  What we
wnat to capture, is whether Travis tests will pass if we apply the
pubspec.yaml changes to the g3v1x branch and then regenerate the
pubspec.lock file.  This commit inserts a custom merge driver for git to
ignore changes to the pubspec.lock file during merging to achieve this.
chore(travis): (fix) custom merge pubspec.lock for g3v1x rebases

Use the current version and not the ancestor version.  This means that
the merge driver has nothing to do except exist.
chore(travis): fail jobs that have a mismatched pubspec.lock

We expect that, for a clean checkout, running "pub get" will not update
the pubspec.lock file.  Any such updates should have been made along
with the corresponding change to pubspec.yaml or must be part of the
commit being tested.  Otherwise, that specific job should fail so the
author can resubmit with the updated pubspec.lock file.