Move to WebSandboxSupport::getFontFamilyForCharacter now that Content supports it

I also removed WebFontInfo::familyForCharacters now that Content no longer uses it.

This is part 3 of 4 for moving away from plumbing UChar16*/length
everywhere to just passing a single UChar32.

Part 1: https://codereview.chromium.org/20732003
Part 2: https://codereview.chromium.org/20883004

The only caller of this API (FontFastPath) already had a UChar32
and never called the previous API with anything other than
length=1 or length=2.

I had to update all implementations of FontCache::getFontDataForCharacter
to the new version.  FontCacheChromiumWin calls getFallbackFamily
which currently expects a UChar16*/Length pair.  I chose not to
go update getFallbackFamily, but rather just move the UChar32 splitting
code from FontFastPath into FontCacheChromiumWin for now.

This should be no change in behavior.  Only simplifying plumbing.
Earlier in this change-series the promise that we were only
ever passed 1 or 2 utf-16 codepoints was lost along the plumbing
resulting in the final endpoint in the browser doing too much work.
That behavior has since been fixed, this just cleans up the
plumbing to make the new behavior (assuming a single UChar32)
more obviously correct.

BUG=266214

Review URL: https://chromiumcodereview.appspot.com/21513007

git-svn-id: svn://svn.chromium.org/blink/trunk@155433 bbb929c8-8fbe-4397-9dbb-9b2b20218538