docs($compile): fix param description being displayed as code block

Closes #4187
docs(guide/$location): replace host.com addresses with example.com

The host.com links on this documentation page took you to an ad page of dubious content.
Now changed to example.com, in accordance with RFC 2606

Closes #4206
docs(ngClass): clarify the description

Closes #4220
docs(ngInclude): clarity, formatting

Closes #4222
docs(guide/$location): fix broken example demo

The demo of the hash-bang vs html5-mode deep links was broken since the introduction
of a check for previously bootstrapped elements. See this commit: 3ee744cc63

We fix this problem by applying a null for the injector value of the element of the
at the root of the sub-app.
It also turns out that it was not necessary, and if fact broke the demo, to replace
the $document service for the sub-app.  This was because the $compile service calls
`$document.createElement()`, which doesn't exist on a `div`.
Finally, the bootstrap CSS was limiting the width of the ngAddress bar input box,
which made it difficult to see the changing URLs.
docs(rootScope): improve grammar and clarity

Closes #4234
docs($sce): fix punctuation

Closes #4235
docs(angular.bind): clarify that bind is partial application

The `angular.bind` function reflects the definition of "partial application", which
reduces a function's arity rather than transforming a function with n args into a
chain of n functions, each having a single arg.

curry : f(x,y,z) -> f(x)(y)(z)
partial application : f(x,y,z) -> f(x)(y,z)

Closes #4239
docs(guide/directive): fix indentation in example code

Closes #4241
docs(guide/directive): clarify use of binding to scopes

The use of 'angular' as sample text is confusing to the newbie in that they are forced
to confirm that the text 'angular' is not a keyword or otherwise referring to a system
component. This is changed to a more obvious sample text.

The most common form of `ngBind` is moved to the top of the list.

Closes #4237
fix($compile): fix (reverse) directive postLink fn execution order

previously the compile/link fns executed in this order controlled via priority:

- CompilePriorityHigh, CompilePriorityMedium, CompilePriorityLow
- PreLinkPriorityHigh, PreLinkPriorityMedium, PreLinkPriorityLow
- link children
- PostLinkPriorityHigh, PostLinkPriorityMedium, PostLinkPriorityLow

This was changed to:

- CompilePriorityHigh, CompilePriorityMedium, CompilePriorityLow
- PreLinkPriorityHigh, PreLinkPriorityMedium, PreLinkPriorityLow
- link children
- PostLinkPriorityLow, PostLinkPriorityMedium , PostLinkPriorityHigh

Using this order the child transclusion directive that gets replaced
onto the current element get executed correctly (see issue #3558),
and more generally, the order of execution of post linking function
makes more sense. The incorrect order was an oversight that has
gone unnoticed for many suns and moons.

(FYI: postLink functions are the default linking functions)

BREAKING CHANGE: the order of postLink fn is now mirror opposite of
the order in which corresponding preLinking and compile functions
execute.

Very few directives in practice rely on order of postLinking function
(unlike on the order of compile functions), so in the rare case
of this change affecting an existing directive, it might be necessary
to convert it to a preLinking function or give it negative priority
(look at the diff of this commit to see how an internal attribute
interpolation directive was adjusted).

Closes #3558
fix($compile): don't terminate compilation for regular transclusion directives

Previously we would stop the compilation for both regular and element
transclusion directives which was wrong. Only element transclusion directives
should be terminal.