Fix offset computation for attributes in command line XML parser

The position XML parser is a specialized DOM parser which keeps track
of offsets. This is used by lint and the manifest merger in order to
provide accurate error position information.

There is no SAX callback for individual attributes, so the way the
parser is able to compute accurate offset information for individual
attribute nodes is to keep the original XML source document around,
and when offsets are requested, it will search within the element
document range for the corresponding attribute declarations using
regexps to find the right tokens.

There were two bugs in this area, which manifested itself as the wrong
attributes being shown in lint error output messages (when lint is run
from the command line; in IDEs we use the native XML AST support which
does track offsets accurately) :

(1) When searching for an attribute declaration, if the target
    attribute does not have a namespace prefix, *and* the there is a
    different declaration of that attribute *with* a namespace prefix
    which is declared earlier, the parser would match the other
    (namespaced) attribute. In other words, if an element declares
    both "android:orientation" and "orientation", a node offset lookup
    for the "orientation" attribute would return the range for the
    "android:orientation" node.

    The fix for this bug is to make the search regexp explicitly make
    sure it does not have a prefix character before the name match.

(2) In some cases (with multiple attributes on a single line), it would
    include more than one attribute in the range. The reason for this
    was that the regexp would (after finding the opening quote) search
    for the closing quote. However, the regexp gladly matched not the
    next quote but the last one on the line.

    The fix here was to insert a reluctant qualifier into the regexp.

A number of unit tests were updated to reflect the now correct
attribute ranges. I spotted one error range being off in the
MissingDetectorTexts and went in and fix it, and I was really
surprised to see how many other places this had crept in without me
noticing!

Change-Id: I29a630d065b7c287092a75114d429fa0a00d8631
Fix FQCN to internal class name conversion.

When converting FQCN (class names in the form of foo.bar.Foo.Bar) to
internal names (of the form foo/bar/Foo$Bar), we assume that components
that start with upper case letters are class names.

However, we also use this method when we have an unambiguous FQCN of the
form foo.Bar.Foo$Bar. This changeset bypasses the heuristics when we
have an unambiguous case.

Bug: http://b.android.com/74140
Change-Id: Ic21aa2365949f9cf95ead1082c770750bd0527fc
Merge "Fix FQCN to internal class name conversion." into idea133
Merge "Fix FQCN to internal class name conversion." into idea133
automerge: 2dad3de

* commit '2dad3de04888b747c12ccd995d6931cdd46b6602':
  Fix FQCN to internal class name conversion.
update to gradle-2.2-20140916220025+0000

Change-Id: Ib24d3336b9c6460bf7129365780bbf1282a093b2
Merge "update to gradle-2.2-20140916220025+0000" into gradle-dev
Updated .iml

Change-Id: Ida3332a1fd6163a43da650c2c2c5123faf771dfe
Merge "Updated .iml" into gradle-dev
Merge "Fix offset computation for attributes in command line XML parser" into idea133
Merge "Fix offset computation for attributes in command line XML parser" into idea133
automerge: defebbf

* commit 'defebbfcec2b3552895549914d083b49c57b5f4d':
  Fix offset computation for attributes in command line XML parser
Update test golden file to reflect new recommended Gradle plugin

Change-Id: I8a6b6db6915cb25733c4dd7eeb7220b4d560e264
Merge "Update test golden file to reflect new recommended Gradle plugin" into idea133
Merge "Update test golden file to reflect new recommended Gradle plugin" into idea133
automerge: ae96336

* commit 'ae963364b704a30abbedd707a36ba71294959996':
  Update test golden file to reflect new recommended Gradle plugin