Fix keyword search erroneously not triggering in two obscure cases:

Fix keyword search erroneously not triggering in two obscure cases:
(1) User types something that doesn't look at all like a keyword (e.g. "go om") and gets a non-default dropdown result that does look like a keyword ("google.com").  Arrowing down to this result, the user then presses space after the keyword name.
(2) Similar to the case above, but this time the non-default result in question looks like a keyword + some more text, with no whitespace between ("google.comxxx").  The user arrows to this result, arrows back to just after the keyword, and presses space.

Item (2) was happening because ShouldAllowExactKeywordMatch() (which has now been renamed) was always looking at the old |user_text_| as the "before change" text, which was wrong if there was temporary text, since the user text was not visible at that point.  Fixed by getting the actual displayed text in that case.

Item (1) was happening for similar reasons, but in MaybeAcceptKeywordBySpace() instead.  This could have been fixed by the same change as above.  However, I elected to change this function to look at the |keyword_| instead of the previously-displayed text, as in https://chromiumcodereview.appspot.com/9289034/ patch set 1.  Not only is this slightly simpler, it is more robust against future changes.  Let's say that someday we want to allow a provider to show a keyword hint for keyword "foobar" on input of "foo ".  By checking against |keyword_| in this function, we ensure that in that future case, the space after "foo" will never trigger keyword search mode for "foobar".  (If we ever bother to fix our bugs with keywords containing spaces, this might apply today for those as well.)

I also tried to change the naming and comments of some things for clarity.

BUG=none
TEST=none
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=124745

[Peter Kasting, 2012-03-02 03:38:04]

Mike, please review history_backend.cc, autocomplete_browsertest.cc (trivial
change), and the infrastructure parts of omnibox_view_browsertest.cc.  Note that
this includes your not-yet-landed change to remove the HQP disabling.

James, please review the rest.

[mrossetti, 2012-03-02 17:18:15]

LGTM

Go ahead and commit the change I was going to make in
omnibox_view_browsertest.cc. My change is failing in DeleteItem on mac_rel—yours
is not—and I am still investigating why.

[Peter Kasting, 2012-03-02 18:00:03]

Landed the browsertest framework changes elsewhere, so this change is now just
the parts for James to review.

[James Su, 2012-03-02 22:00:33]

On 2012/03/02 18:00:03, Peter Kasting wrote:
> Landed the browsertest framework changes elsewhere, so this change is now just
> the parts for James to review.

LGTM.