Add Object.keys based clone implementation

I have a scenario where I'm parsing thousands of date strings with moment, and `cloneMoment` was near the top of the more expensive methods by execution time. I believe this is due to using `for..in` to enumerate properties, which also enumerates prototype properties. However, this behavior appears to not be required, since the iterator block here immediately checks for own properties only.

Since this method is only being called in one place where `m` is guaranteed to be a moment object, and only own properties are cloned and prototype enumeration is not a requirement, I have added a preferable implementation using the less-expensive `Object.keys`, which will be used if available ([which it universally is, among non-obsolete browsers](http://kangax.github.io/compat-table/es5/)). The former implementation is retained for obsolete browsers.

This results in a substantial improvement in my actual situation, with the total aggregate time for `cloneMoment` dropping from ~300ms to ~60ms.

All `grunt` tasks pass without issue.
It will, but does it matter? A proper for loop version of this would also initialize the iterator variable to `keys.length`. Is this an aesthetic preference?