Consider switching memoize cache to be compatible with ES6 Map/WeakMap.

At the moment the `_.memoize` cache is just a plain object. If we were to switch it to being a simple wrapper around the cache object (still doing the same param to string key use) but with the interface of ES6 [Map](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map-constructor), [WeakMap](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap-constructor) that would allow devs to swap in ES6 Maps/WeakMaps for their cache. The thin wrapper would have an interface to mimic Map/WreakMap, so [has](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.has), [set](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.set), [get](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.set), and optionally ([delete](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.delete), [clear](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.clear)).

`_.memoize` could have a `Cache` constructor bolted on to it `_.memoize.Cache` to allow devs to swap it out with a Map/WeakMap or equiv shim as well.

Map/WeakMap are available on all modern browsers, node --harmony.

Thoughts?

Start at _.memoize and review the proposed Map/WeakMap-compatible cache interface and the _.memoize.Cache replacement hook. Resolve the API design in the discussion, including which methods are required and how existing string-key behavior is preserved; done means the issue's design questions have a decided implementation scope.

Written by the indexing model from the issue text.