Do not normalize into NFC the values of form fields

This commit renames the TextEncoding::encode(const String&, UnencodableHandling) const
API function to normalizeAndEncode() to make clear that the function
first applies Unicode NFC normalization before encoding the string. All
existing references to encode() except for one were updated to call
normalizeAndEncode() instead.

TextEncoding::encode(const String&, UnencodableHandling) const is added
back as a new API function which only encodes the string, but does not
normalize the string before encoding.

The one call to the old encode() function that was not updated is in
FormDataList::appendString(const String&). This was left as a call to
the new encode() to fix Issue 117128.

Chrome and Safari are unlike other browsers in that they apply Unicode
NFC normalization to form values when submitting a form; in particular,
the following browsers were tested and found not to normalize the form
values:
- Firefox 22.0
- Firefox ESR 17.0.7
- Opera 12.16
- IE 6
- IE 7
- IE 8
- IE 9
- IE 10
- Amaya 11.4.7

NFC normalization actually changes the meaning of text in certain scripts.
Notably, there are certain Biblical Hebrew words for which normalization
causes the word to be erroneously encoded. One example is given on page 9
of the SBL Hebrew Font User Manual version 1.5:
http://www.sbl-site.org/Fonts/SBLHebrewManualv1.5.pdf
This example is added as the new form-data-encoding-3.html layout test.

BUG=117128

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

git-svn-id: svn://svn.chromium.org/blink/trunk@154881 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Add Ian Vollick to core/OWNERS.

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

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