A mix of updates: LatLngBounds, MVCObject, Overlays

Hi Brandon,

We're undertaking an upgrade of our GWT project from Google Maps v2 to v3 and we've decided to use your project as our Maps-to-GWT bridge. Our project is fairly large and I expect we'll need to make a few more changes to your project before we're done but I thought it would be good to submit a pull request early and get a dialogue going.

The changes to LatLngBounds should be fairly uncontroversial, Google's API allows for bounds objects to be constructed without supplying full extents and handles the case gracefully. I do see though that you have a fairly exhaustive set of tests for the class, we'd be willing to add to those tests but we don't use Maven here and I'm having trouble getting the tests to run. I can compile and package the source code and when I execute 'mvn test' I'm told that it was successful, but I'm also told that 0 tests were executed. Is there anything obvious I might be missing or is there anything I can read to help me get up to speed on your setup?

We've started to change the way generics are used in MVCObject but so far just the methods that we're using. Our changes reflect that the Maps API allows MVCObjects to be bound to arbitrary MVCObjects of different types. It seems like other uses of generics in this class should also be corrected:

 * The signature of `set(String, T)` should probably be changed to `set(String, Object)`
 * The signature of `T get(String)` should maybe be something like `public final native <U> U get(String)`, but I'll admit my grasp of generics is not 100% and I'm not so confident on this one.
 * `setValues(HashMap<String,String>)` should probably become `setValues(Map<String,?>)`.

The reason I say 'probably' is that this implementation does expose some potential runtime errors if anyone tries to pass non-JSO objects to the setters, but at the same time these methods should permit String objects and the primitives so it's hard to avoid. Would like to hear your thoughts on this.

We've added a common interface `Overlay` which is implemented by Marker, Polygon, Rectangle et al, which we use for handling visibility and removal of complex overlays composed of many different constituent overlays. It's a fairly inoffensive little interface but it's not in the official API anywhere (I suppose it's unnecessary in javascript), so if you're adamant about remaining faithful to what Google have written down then I guess we'll find a workaround.

The new Icon binding we've added is simple enough. We can add tests for this once we have them working.

Cheers,
Doug Hammond