Bug 1277650 - part 2 - more explicit friending between NativeStubImpl and ProxyNativeCall; r=darchons

clang complains about specializations of NativeStubImpl not being able
to see the private constructor of ProxyNativeCall.  While
ProxyNativeCall includes a friend declaration for NativeStubImpl, it's
not obvious *which* NativeStubImpl is being friended, as NativeStubImpl
hasn't been forward declared and exists in a completely separate
namespace.  Forward declaring NativeStubImpl and adjusting the friend
declaration makes everything more correct.

widget/android/jni/Natives.h

@@ -217,6 +217,13 @@ struct UsesNativeCallProxy
     }
 };
 
+namespace detail {
+
+template<class Traits, class Impl, class Args, bool IsStatic, bool IsVoid>
+class NativeStubImpl;
+
+}
+
 namespace {
 
 // ProxyArg is used to handle JNI ref arguments for proxies. Because a proxied
@@ -266,7 +273,7 @@ template<class Impl, class Owner, bool IsStatic,
 class ProxyNativeCall
 {
     template<class T, class I, class A, bool S, bool V>
-    friend class NativeStubImpl;
+    friend class detail::NativeStubImpl;
 
     // "this arg" refers to the Class::LocalRef (for static methods) or
     // Owner::LocalRef (for instance methods) that we optionally (as indicated
@@ -425,9 +432,6 @@ namespace detail {
 // We need specialization for return type, because void return type requires
 // us to not deal with the return value.
 
-template<class Traits, class Impl, class Args, bool IsStatic, bool IsVoid>
-class NativeStubImpl;
-
 // Bug 1207642 - Work around Dalvik bug by realigning stack on JNI entry
 #ifdef __i386__
 #define MOZ_JNICALL JNICALL __attribute__((force_align_arg_pointer))