Convert Chrome PPAPI proxy from bool to PP_Bool.

ppapi/proxy/interface_proxy.h

Index: ppapi/proxy/interface_proxy.h
===================================================================
--- ppapi/proxy/interface_proxy.h	(revision 65343)
+++ ppapi/proxy/interface_proxy.h	(working copy)
@@ -70,6 +70,14 @@
   const void* target_interface_;
 };
 
+inline PP_Bool BoolToPPBool(bool value) {
+  return value ? PP_TRUE : PP_FALSE;
+}
+
+inline bool PPBoolToBool(PP_Bool value) {
+  return (PP_TRUE == value);
+}

[dmichael(do not use this one), 2010/11/08 15:31:19]

Is there a reason you can't or shouldn't use ppapi/cpp/common.h instead of
defining them separately?  This means that there are both:
pp::BoolToPPBool
and
pp::proxy::BoolToPPBool
defined, and they do exactly the same thing.  It seems slightly odd.  Maybe the
real issue there is whether interface_proxy.h should really put things in the pp
namespace?  If this is a full-fledged member of ppapi, I think it can use the
common.h definitions.  If it's not, maybe we should consider taking it out of
namespace pp (in a future CL).  Thoughts?

[brettw, 2010/11/08 15:51:02]

The proxy layer is actually totally separate from both ppapi/cpp and shouldn't
have any dependencies. ppapi/cpp is for plugins to statically link for
convenience. This proxy code will be compiled and distributed with Chrome
(although it's likewide a PPAPI plugin with no dependencies on the actual
implementation).

[dmichael(do not use this one), 2010/11/08 16:11:51]

That makes sense.  That being the case, I'm not sure if any of the proxy stuff
really belongs in namespace pp, but that's an issue for another CL (if at all).

+
 }  // namespace proxy
 }  // namespace pp