pulling this library into yargs

[bcoe]

• I love this initiative, and would love for you to keep the commit history and own this repo, but we should probably transfer it into the yargs org once it's done: feat: add support for error type #3, feat: add promise support #4, feat: add support for Buffers #5, fix: allow undefined for optional arguments #6, feat: allows this to be the typeConfig string #9
• I'm not quite ready to move yargs to Node 4+, so perhaps we can add a babel transpilation step to this repo, if you want to use newer syntax (for the time being). chore: add babel-cli and config to build lib folder #2
• I'd love to figure out a way to both release this as its own library, and have it shipped with yargs ... maybe the answer is moving to bundled-dependencies like nyc ... alternatively, and maybe better, is looking into how we could pull this workflow off with lerna; basically, I'd like to be able to release yargs' modules both individually, and in a bundle with yargs.
• awesome README 😛 docs: add readme #8, docs: add live example and update tests #10

[bcoe]

@JaKXz regarding the arguments performance discussion; I wonder if there's a second repo we could be releasing that just encapsulates this performant slice step ... maybe this is over-kill.

[bcoe]

... pretty ugly, but: https://github.com/stefanpenner/sweet-array-slice

[JaKXz]

re: the Array.slice.call(arguments) issue, looking at the babel transpiled code I'm not seeing that call anywhere: https://gist.github.com/JaKXz/c7f077d271a441e8d717008b885019bb

It does arguments[_key] in a for loop where _key is incremented, but I don't think that's terrible since it's essentially just a hash lookup right?

cc @iarna

[iarna]

Accessing indexes of arguments is fine. IIRC, it's not even a hash lookup because arguments is magic, it's like, a C-level array index access.

[JaKXz]

@bcoe when do you want me to make the transfer? ✅