Updated suborigin serialization to latest spec proposal

url/url_constants.h

Index: url/url_constants.h
diff --git a/url/url_constants.h b/url/url_constants.h
index 3a423d2634201ba18aa1578db9f8500c2f3ff881..5fbf64b0a4b3a25bedb53e0314462aa073df17cf 100644
--- a/url/url_constants.h
+++ b/url/url_constants.h
@@ -24,7 +24,9 @@ URL_EXPORT extern const char kFileSystemScheme[];
 URL_EXPORT extern const char kFtpScheme[];
 URL_EXPORT extern const char kGopherScheme[];
 URL_EXPORT extern const char kHttpScheme[];
+URL_EXPORT extern const char kHttpSuboriginScheme[];
 URL_EXPORT extern const char kHttpsScheme[];
+URL_EXPORT extern const char kHttpsSuboriginScheme[];

[Mike West, 2016/09/13 18:00:18]

I don't think it's a good idea to let these live in //url. They're a platform
concept, and could instead be injected by //content (see
//content/common/url_schemes.cc, for example).

[jww, 2016/09/13 18:36:04]

Aren't blob:, javascript:, and filesystem also platform concepts? That having
been said, I suppose it keeps things cleaner, especially since it's not
explicitly used inside of GURL, so I updated it to register it through content.
I spoke to sleevi about this a few days ago, though, and it does seem like
there's some future where it would be useful and good to explicitly teach GURL
about suborigins (but that day is not today).

 URL_EXPORT extern const char kJavaScriptScheme[];
 URL_EXPORT extern const char kMailToScheme[];
 URL_EXPORT extern const char kWsScheme[];