Safe mutable attributed string copying on modern OS X

Applications linked on 10.6 and below decode an encoded `NSMutableAttributedString` as it was given. When linked on Lion and up, `NSMutableAttributedString` is encoded in a format that *when running on Lion and up* comes back as [`NSConcreteAttributedString`](https://github.com/yyfrankyy/iOS5.1-Framework-Headers/blob/master/Foundation.framework/NSConcreteAttributedString.h). For its `contentString` field, NoteObject doesn't copy the representation returned from the decoder, which means that the app will try and perform mutable actions on an immutable string. In a less well-designed app, that'd mean crashes left and right; here, it's just a completely blank UI. Trade-offs.

In a fork, I have the for-want-of-a-nail pet project of modernizing nvALT. I don't say this as a [because I want thousands of eyes on it](http://i.imgur.com/B1fpQqx.png); I really don't, I'm just a student playing around in his free time for learning purposes. It's a twisted hobby. This self-serving pull request enables surprisingly-perfect forwards compatibility by mutably copying the string, which is a technique Apple recommends in modern code. It might be silly to want to enable near-full compatibility for code that probably shouldn't/won't ever gain traction, but I wouldn't want for anyone (myself included) to have to nuke their `Notes & Settings` for any reason. Furthermore, if Foundation in Space Lion were to force attributed string decoding to act like this for any reason, this change would have to be made anyway.

Thanks for the consideration!