Add an FAQ Section about rate limiting/API Key security

[tmwbook]

While developing an app that didn't really need the OAuth flow, I was wondering how I was going to keep my api-key from getting rate limited or stolen if I have to give embed it so it is in every request to the API. When researching the problem I came across https://github.com/Bungie-net/api/issues/998#issuecomment-518323255 (the whole thread really) which answered the question nicely.

Maybe I'm blind, but as far as I can see neither the Wiki nor the openapi docs have any mention of an IP based limit. The API key being public may be a reasonable intuition to make, but it is under the Security section of the open api spec and other web services often use key-based limiting, so it may be worth mentioning that its more of an attribution tool as well.

Just a brief section of the Wiki FAQ along the lines of:

Title: How are applications rate limited?

Content: 
The api will return a <InsertErrorNameHere> error for any requests that exceed 25 req/second.
This limit is enforced by IP and is a general limit for the API.
There are some endpoints that have stricter limits placed on them such as Transfer which has a per account rate limit.

Title: What is my API Key used for?

Content:
The API Key (not client_id, and especially not client_secret!) is simply used as a soft indicator of what application is issuing the request to the api.
Given that the API Key is required in all requests, there is no expectation of privacy for this value, and can safely be packaged along with your application

[tmwbook]

After reading even more of the issue, I also found https://github.com/Bungie-net/api/issues/998#issuecomment-518377853 which says that there is a per-key throttle, but that it is not the primary rate limiting system. So it may be more accurate to append to the end of the first page:

While there is a general rate limit on individual api keys, it is not the primary way the api is rate limited. We trust developers to be good citizens when creating applications and this limit is not something that should be reached under normal use of the api.