Clarify notification scheme on watched projects

Since 2.1.4 when watching All-Projects became possible
(e7d485ccc478d5a1a1fcdd579251b93c22a8db1f), the presence of a
specific project match would exclude All-Projects rules from being
processed.  This was never clearly documented, although the change
(https://gerrit-review.googlesource.com/15556) and related issue
(Issue 535) discussed why this was the case.

This clarifies the documentation to mention that an All-Projects
watch will be superceded by a more specific project watch, and
changes the behavior such that a more specific project watch will
only prevent a notification at the All-Projects level if the filter
matches.

Change-Id: I7056f692047ccf00f61107cb6ec0d39335131254
HashtagsUtil: Add method to extract hashtags from a commit message

Change-Id: I3778f9c8e1174a0b126d06186e1f038b7968d557
SideBySide2: Fix alignment for long insertion/deletion blocks

In commit 1dbc53126cafc0f553b709 the line-height was changed to
"normal", allowing for taller text lines. Padding for insertion
or deletion blocks was no longer tall enough, which caused the
two sides to stop aligning.

Correct this by computing the line height on the fly after the
UI is displayed and the browser was able to compute font metrics
to a sampling of 10 lines of text.

Use the guessed value from a prior rendering for the new one,
reducing any reflow that has to occur upon viewing another
file in the same application session.

Chrome on Linux is showing the lines are 15px tall, so use
that as the current default guess, reducing initial reflow
for any platform that has this font height.

Bug: issue 2970
Change-Id: Ic5f7dbbd1cc3582388cfcdf6faf9dca1f7a85fa0
(cherry picked from commit 941d32cff210e3bec4e114ea35822b017faf18f1)
Update 2.10 release notes

Change-Id: Ie130be8f6bb9e20e88be9f1b481e1f2853f033db
Organize imports

Change-Id: I88b40b66661d92c48ab1ff6a4cff4825d109d78d
Make bug report URL unset by default

There are still many issues [1, 2, 3 and more] being reported on the
Gerrit issue tracker that are not related to Gerrit at all.  These are
most likely from users who have blindly clicked through from a Gerrit
site that is installed with the defaults.

The default URL makes sense on gerrit-review.googlesource.com because
it's most likely that users do actually want to report a bug on Gerrit
itself.

However for most other cases, many users are going to assume that it
links to the issue tracker for the project(s) that is/are being reviewed.
As an example of this, we see quite a lot of issues being reported from
the cyanogenmod review site [4] and the Android open source project's
review site [5].  Both of those are set up with the default URL.

Instead of defaulting to the Gerrit issue tracker, leave the bug report
URL unset if not explicitly specified in the config.

This change effects all installations, newly initialized or already
existing.

The site configuration for gerrit-review.googlesource.com will need to
be updated to explicitly configure the bug report URL.

[1] http://code.google.com/p/gerrit/issues/detail?id=3037
[2] http://code.google.com/p/gerrit/issues/detail?id=3036
[3] http://code.google.com/p/gerrit/issues/detail?id=3028
[4] http://review.cyanogenmod.org/
[5] https://android-review.googlesource.com/

Change-Id: I5c87d456868c37d9bf4cf42dc2ec93beab3444c4
Fix minor python code style issues

Fix some minor issues that were reported by pyflakes and pylint.

- Rename arguments to prevent redefinition of built-in 'dir'
- Rename method call to prevent redefinition of built-in 'help'
- Remove unused imports
- Prefix unused variable with underscore to prevent warning

Change-Id: Ia9e21c0f1a69af43f6e4566be46c31bdda540d2f
Fix trailing whitespaces in all files

Change-Id: Ia310c92b036d0c8b89deb1eee362cf2bed9eb3e2
Use addParameterTrue to avoid =t in edit RPC URLs

Bare variables in the URL such as ?list are accepted as boolean
true by the server endpoints. Avoid ?list=t and just use ?list
to match all other REST API calls made by the UI.

Change-Id: I298a9c0254601898f29f74b7aebfa6564829fd5f
Remove metaVars for booleans of /edits

metaVar documentation is only necessary for string/int/enum
type of variables where there is an argument being supplied.

Change-Id: I7849d7c97d8054246524f969de71893fdac0242e
Revert "Don't sort labels alphabetically in UI"

This reverts commit d5bbe0841fb3b6ec2ca7dd7f28bb9bccb857c9c1.

Labels are returned to the browser inside of a map/object
whose ordering is undefined once parsed into a JavaScript
object for use by the UI.

By removing client side sorting we are at the mercy of
the browser's iteration of map/object keys, which can be
different across versions or implementations.

A correct solution to rely on project defined ordering
will require exporting the project defined ordering in
the label data, or as part of the project config read
for the change. But just dropping client side sorting is
not a solution.

Change-Id: Ib7c9ba241a8d1d97c5106f22059f71ca43f55a2d
Merge "Revert "Don't sort labels alphabetically in UI""
Merge "Fix trailing whitespaces in all files"
Fix documentation for merge strategy 'fast-forward-only'

The documentation for merge strategy 'fast-forward-only' asserts that
fast-forward-only produces a strictly linear history. But even with
fast-forward-only it is possible to produce histories not being strictly
linear. E.g. some predecessors of the change being pushed might be
merge commits. The point is that by submitting a change no merge
commit will be created when merge strategy is fast-forward-only.

Change-Id: Ia68e6bac7fb49b1398971e7a23d4277f1ca51b06
Merge "Fix documentation for merge strategy 'fast-forward-only'"
Merge "Organize imports"
Merge "Make bug report URL unset by default"
Merge "Fix minor python code style issues"
Merge "Clarify notification scheme on watched projects"
Merge "HashtagsUtil: Add method to extract hashtags from a commit message"