Move cloud_print manifestdependency to external .manifest file

I plan (https://codereview.chromium.org/111373002/) to make manifest
handling simpler in gyp. In particular, doing the manifest embedding
in one pass to avoid the need to invoke the linker twice.

In order to do this /manifestdependency on the linker command line needs
to be removed as it creates dependencies that are only made clear by
having the linker generate a manifest. In this case it's simple enough
to simply use a .manifest file with the same dependency information that
can be merged beforehand.

So, move from .gyp linker flags to a file in AdditionalManifestFiles.

R=vitalybuka@chromium.org
BUG=324863

Review URL: https://codereview.chromium.org/108813005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240189 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 240189
Stop doing unnecessary UTF-8 to UTF-16 conversions in JSONWriter.

The JSONReader only accepts UTF-8 input strings and converts \uXXXX sequences
back into UTF-8. However, the JSONWriter converts all non-ASCII characters to
UTF-16 escape sequences. This round-tripping is sub-optimal, as noted in a
TODO from r54359.

One reason for this may be that JsonDoubleQuote(), used by JSONWriter, does not
handle UTF-8 bytes correctly, interpreting them as code points and writing them
out as \u00XX sequences. If this were read back through a RFC-compliant JSON
parser, the result would be an invalid encoding error. JsonDoubleQuote() does
handle UTF-16 correctly, though.

This rewrites the base/json/string_escape.h API and fixes the above UTF-8 issue
by dividing callers up into three groups:

1. Those that pass valid UTF-8 to be escaped. Prior to this change, very few
   callers used this variant. Those that did were likely using ASCII, otherwise
   the output would be mangled due to the above issue. Now, valid UTF-8 will be
   passed through to the output unescaped. Invalid UTF-8 sequences are replaced
   with U+FFFD.

2. Those that pass valid UTF-16 to be escaped. This function now validates that
   the input is valid UTF-16, and then converts it to unescaped UTF-8 sequences
   for the output.

3. Those that pass arbitrary byte arrays as std::string and expect a non-RFC-
   compliant encoding of the binary data using \uXXXX escapes. This behavior is
   now in the EscapeBytesAsInvalidJSONString() function. It is only used by
   callers who want a "debug string" but do not expect to actually parse the
   output as valid JSON, since it is not.

Additionally, this removes the JSONWriter::OPTIONS_DO_NOT_ESCAPE flag, since
the writer can now handle UTF-8 appropriately.

BUG=15466

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=239800
Reverted: https://src.chromium.org/viewvc/chrome?view=rev&revision=240082

R=asanka@chromium.org, bauerb@chromium.org, mark@chromium.org, thakis@chromium.org, zea@chromium.org

Review URL: https://codereview.chromium.org/100823007

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240190 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 240190
Update breakpad revision in DEPS

Bring in the latest Breakpad, which cleans up its build rules
so bots won't randomly try to run automake/autoconf uselessly
(and sometimes fail).

BUG= none
TEST= none
R=bradnelson@google.com

Review URL: https://codereview.chromium.org/107933004

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240193 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 240193