Public API v3 support

[dawsbot]

Removes Public API calls for v2 functions and implements v3. In addition, you can now enter a value in to the "limit" field to restrict how many output values you receive on calls to trades() and depth(). Resolves tickets #4 and #10.
Removes function:

• fee() Adds function:
• info
  
  Adds optional "limit" field to:
• trades()
• depth()

[pskupinski]

I'm glad you took the time to take a look at this issue, but I see numerous problems with this. I just can't see myself merging this in without significant changes.

Here is some feedback:

• Keeping the api method names the same seems like a mistake to me unless we make sure that the output format remains the same, there are api methods where the output differs from v2 to v3. I don't want to break software that is relying on output from this api wrapper being a certain way.
  • A good example being https://btc-e.com/api/2/ltc_btc/trades and https://btc-e.com/api/3/trades/ltc_btc, certain fields are not present in v3 that were present in v3 such as price_currency and item.
  • Another example being https://btc-e.com/api/2/ltc_btc/ticker and https://btc-e.com/api/3/ticker/ltc_btc, server_time is not present in the v3 output, and as is my ticker method would return a different format than yours, it would contain the "ticker" wrapper object that can be seen in the v2 output that is not present in the v3 output.
• There isn't a point in removing the fee api method if it still works. Seems like an unnecessary breaking change.
• Your changes are really sloppy in many areas, just take another look at your changes in makePublicApiRequest as an example. I'd basically need to rewrite most of that.
• Should add support for specifying multiple pairs and ignoring invalid pairs https://btc-e.com/api/3/docs#main.
• Adding limit as a parameter after the callback doesn't seem right. The pair parameter should instead be made to accept a pair or pairs, or an object with limit specified optionally and the pair or pairs. Basically, take advantage of the dynamic nature of javascript and treat the parameter differently whether it is passed in as a string, array or object. This ties in with the above note.

I just don't think this is the right approach overall, so I'm going to close this. I really appreciate that you submitted this pull request though.

[dawsbot]

Thank you for your response, I will take your advice and try to improve my programming for my future endeavors.