Add a version of AdjustStringForLocaleDirection() that handles the quirks of GTK/OSX label autodirectionality.

Comment from the CL:
// On OS X & GTK the directionality of a label is determined by the first
// strongly directional character.
// However, we want to make sure that in an LTR-language UI all strings are
// left aligned and vice versa.
// A problem can arise if we display a string which starts with user input.
// User input may be the opposite directionality and so the whole string will
// be displayed in the opposite directionality, e.g. if we want to display in
// an LTR UI [such as US English]:
//
// EMAN_NOISNETXE is now installed.
//
// Since EXTENSION_NAME begins with a strong RTL char, the label's
// directionality will be set to RTL and the string will be displayed visually
// as:
//
// .is now installed EMAN_NOISNETXE
//
// In order to solve this issue, we prepend an LRM to the string which is a
// strongly directional LTR char.
// We also append an LRM at the end which ensures that we're in an LTR
// context.

// Unlike Windows, Linux and OS X can correctly display RTL glyphs out of the
// box so there is no issue with displaying zero-width bidi control characters
// on any system.  Thus no need for the !IsRTL() check here.

BUG=63303
TEST=1. Try scenario described in bug. 2. Make sure there areno regressions displaying RTL strings in LTR UI and vice versa on OS X.

Review URL: http://codereview.chromium.org/5291009

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68967 0039d316-1c4b-4281-b951-d872f2087c98