Move SafeManifestParser to //extensions

Move SafeManifestParser to //extensions

This moves SafeManifestParser to extensions_browser.
Also creates a new ExtensionUtility IPC message class in which
to define extensions utility process messages. The relevant
manifest parsing messages have been moved into this class.

BUG=398671
Committed: https://crrev.com/eb6d47fab5dc127b474363d488aa1b6ccbfa7b48
Cr-Commit-Position: refs/heads/master@{#296508}

[Ken Rockot(use gerrit already), 2014-08-13 21:03:51]

Antony, could you take a look for extensions stuff?

[asargent_no_longer_on_chrome, 2014-08-13 21:14:29]

lgtm

[Ken Rockot(use gerrit already), 2014-08-13 21:21:26]

palmer@ could you please review the changes in ipc_message_start.h and
*_messages.h? This is just moving existing messages into a new message class.

[Ken Rockot(use gerrit already), 2014-08-15 14:48:56]

ping palmer@ for IPC message relocation

[palmer, 2014-08-18 18:08:31]

https://codereview.chromium.org/464613002/diff/160001/extensions/common/exten...
File extensions/common/extension_utility_messages.h (right):

https://codereview.chromium.org/464613002/diff/160001/extensions/common/exten...
extensions/common/extension_utility_messages.h:33: std::string /* xml document
contents */)
What if the document is huge? Does it make sense to make this be a shared memory
segment instead, or something? Or is there a sensible size limit?

https://codereview.chromium.org/464613002/diff/160001/extensions/common/exten...
extensions/common/extension_utility_messages.h:47: std::string /* error_message,
if any */)
If possible, it's generally better to indicate errors with an enum, and then for
stringification have the IPC recipient map the enum values to strings.

[Ken Rockot(use gerrit already), 2014-09-22 21:32:13]

On 2014/08/18 18:08:31, Chromium Palmer wrote:
>
https://codereview.chromium.org/464613002/diff/160001/extensions/common/exten...
> File extensions/common/extension_utility_messages.h (right):
> 
>
https://codereview.chromium.org/464613002/diff/160001/extensions/common/exten...
> extensions/common/extension_utility_messages.h:33: std::string /* xml document
> contents */)
> What if the document is huge? Does it make sense to make this be a shared
memory
> segment instead, or something? Or is there a sensible size limit?
> 
>
https://codereview.chromium.org/464613002/diff/160001/extensions/common/exten...
> extensions/common/extension_utility_messages.h:47: std::string /*
error_message,
> if any */)
> If possible, it's generally better to indicate errors with an enum, and then
for
> stringification have the IPC recipient map the enum values to strings.

I think these are both reasonable suggestions, but I'm only moving existing code
with this CL. I would
rather not fundamentally change the IPCs' structure at the same time. WDYT?

[palmer, 2014-09-23 20:42:36]

> > If possible, it's generally better to indicate errors with an enum, and then
> for
> > stringification have the IPC recipient map the enum values to strings.
> 
> I think these are both reasonable suggestions, but I'm only moving existing
code
> with this CL. I would
> rather not fundamentally change the IPCs' structure at the same time. WDYT?

If you file a bug for it and CC me, LGTM. Thanks!

[Ken Rockot(use gerrit already), 2014-09-24 19:20:48]

Thanks, done. http://crbug.com/417382

[Ken Rockot(use gerrit already), 2014-09-24 19:38:47]

The CQ bit was checked by rockot@chromium.org

[commit-bot: I haz the power, 2014-09-24 19:39:41]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/464613002/220001

[commit-bot: I haz the power, 2014-09-24 20:32:01]

Committed patchset #5 (id:220001) as 31699a4fc63c148fe84ab46d31b81edba42d153e

[commit-bot: I haz the power, 2014-09-24 20:32:33]

Patchset 5 (id:??) landed as
https://crrev.com/eb6d47fab5dc127b474363d488aa1b6ccbfa7b48
Cr-Commit-Position: refs/heads/master@{#296508}