Remove internal uses of mojo::Array and mojo::WTFArray.

mojo/public/cpp/bindings/lib/hash_util.h

Index: mojo/public/cpp/bindings/lib/hash_util.h
diff --git a/mojo/public/cpp/bindings/lib/hash_util.h b/mojo/public/cpp/bindings/lib/hash_util.h
index c37599c4ce2a59295c728c24dd3e399248f3a075..93280d69daf2f4842e74302f0cc7af7480530c2c 100644
--- a/mojo/public/cpp/bindings/lib/hash_util.h
+++ b/mojo/public/cpp/bindings/lib/hash_util.h
@@ -10,6 +10,7 @@
 #include <type_traits>
 #include <vector>
 
+#include "base/optional.h"
 #include "mojo/public/cpp/bindings/lib/template_util.h"
 
 namespace mojo {
@@ -63,6 +64,16 @@ struct HashTraits<std::vector<T>, false> {
 };
 
 template <typename T>
+struct HashTraits<base::Optional<std::vector<T>>, false> {

[yzshen1, 2017/01/03 19:26:26]

Does it make sense to make this a template with template parameter
base::Optional<T>?

[Sam McNally, 2017/01/03 23:52:04]

I thought about that, but it seemed nicer to use std::hash except where we need
something different.

[yzshen1, 2017/01/04 18:05:48]

There might be reasons that I have forgotten: why do we 

I haven't understood your idea: why having a HashTraits<base::Optional<T>>
definition will drive people away from std::hash? Would you please explain?

[Sam McNally, 2017/01/04 22:58:35]

I mostly wanted to avoid the redundancy of HashTraits<base::Optional<T>> when
HashTraits<T, false> would suffice by using std::hash<T> (where T =
base::Optional<U>).

+  static size_t Hash(size_t seed, const base::Optional<std::vector<T>>& value) {
+    if (!value)
+      return HashCombine(seed, 0);
+
+    return Hash(seed, *value);
+  }
+};
+
+template <typename T>
 size_t Hash(size_t seed, const T& value) {
   return HashTraits<T>::Hash(seed, value);
 }