Align base::hash_map with C++11.

Align base::hash_map with C++11.

The MSVC ones have considerably different requirements than
the C++11 ones and the __gnu_cxx ones we use. Notably, they
require a global ordering on the key. Expose
std::unordered_map as base::hash_map instead.

For non-MSVC, the API is much closer, but the default hash
function is off; T* doesn't have a hash by pointer value,
and const char* hashes by C string (despite comparing by
pointer value). Swap the default hash with one intended to
match the C++11 semantics.

BUG=none

[davidben, 2014-10-02 22:38:50]

[Not sending this out for review yet. Just hitting publish to make the comment
visible.]

https://codereview.chromium.org/612323010/diff/100001/base/containers/small_m...
File base/containers/small_map_unittest.cc (left):

https://codereview.chromium.org/612323010/diff/100001/base/containers/small_m...
base/containers/small_map_unittest.cc:417: hash_map_add_item() : hash_map<int,
int>() {}
This is to work around an incredibly annoying problem with type aliases. If we
were to call it base::unordered_map, I think we would avoid this problem.

The trouble is that we're subclassing base::hash_map<int, int>. But within
base::hash_map, 'hash_map' is bound to std::hash_map. And so inside the
subclass, we inherit the parent class's binding of 'hash_map' over the one in
base. I believe this is similar why this works:

  namespace a {
  struct Foo {};
  }
  struct Bar : public a::Foo {
    Bar() : Foo() {}
  };

And this:

  namespace a {
  struct Foo {};
  typedef Foo Foo2;
  }
  struct Bar : public a::Foo2 {
    Bar() : Foo() {}
  };

But not this:

  namespace a {
  struct Foo {};
  typedef Foo Foo2;
  }
  struct Bar : public a::Foo2 {
    Bar() : Foo2() {}
  };


I'm going to leave it as-is for now since subclassing hash_map is a bizarre
thing to do, but we may want do the rename now to avoid this.

[davidben, 2014-10-02 22:53:59]

[another publish-only comment]

https://codereview.chromium.org/612323010/diff/100001/content/renderer/pepper...
File content/renderer/pepper/v8_var_converter.cc (left):

https://codereview.chromium.org/612323010/diff/100001/content/renderer/pepper...
content/renderer/pepper/v8_var_converter.cc:50: bool operator<(const
HashedHandle& h) const { return hash() < h.hash(); }
I left the other operator<'s in place because it wasn't immediately clear
whether a std::map of them would have made sense in each case...

...except this one. This one looks pretty clearly nonsense. Unless
GetIdentityHash() is secretly GetIdentityUniqueValue(), we weren't handling hash
collisions on MSVC's hash_map. It doesn't use operator==.