Fix #45 - Rename global method to a library-specific name, to avoid interfering with other libraries

[mful]

Alternatively we could wrap the method in a module, and include it in the relevant places. Chose not to do this, because I was not sure how editable files that start with are:

### WARNING: This file is auto-generated by the asana-api-meta repo. Do not
### edit it manually.

┆Issue is synchronized with this Asana task

[markchua]

You'll need to make changes in the asana-api-meta repo for those. The files are automatically generated so any changes you make won't persist.

[praecipula]

Hey @mful, as @markchua said, we do indeed generate those files, so when we regenerate the code, all the changes would be lost. It would be relatively trivial to make the change in asana-api-meta to nest everything in a module (it's essentially just a templating system, sort of like erb if you're familiar, that generates the code), and I think namespacing like this would have been the right thing to do at the beginning. The tricky part now, I think, is that we have people using the library that would see naively doing this as a breaking change when they update, so we'll have to give some thought about when and how it's right to introduce the change. Perhaps we could provide an alternate require that wraps the existing code under an asana module, and users could choose one or the other... we'll give it some thought!

[mful]

To make sure I understand, the idea is to wrap this guy in a module and then update this declaration?

Is there process on coordinating changes between these two libraries that I should be aware of?

Assuming the changes happen "simultaneously", I don't see how this would be a breaking change @praecipula — what am I missing?