Issue title: Slash command inputs for integers greater than 2^53 are converted to string
 Issue body: **Description**

Slash command with an integer option will convert the integer to string and is likely to have off by one errors if the input is above `2^54` (`9007199254740992`) or below `-(2^53)`
- Interactions with `9007199254740992` will be correct
- Interactions with `9007199254740993` will return `9007199254740992` as a number in the interaction JSON
- Interactions above `9007199254740993` will return the input as a string in the interaction JSON, and often be off by one.
  - e.g. `9007199254740995` -> `9007199254740996`
  - e.g. `9999999999999999`  -> `10000000000000000`

**Steps to Reproduce**

1. Post a new slash command to a guild with an Integer type option.
2. Run an app that will simply acknowledge interactions and not consume source.
3. On the desktop client input `9007199254740993` as the integer for the option
4. The source will say you ran the command with `9007199254740992` as the integer input.

**Expected Behavior**

Either:
- The interaction data JSON has the correct number as a number not a string

Or:
- Give the user an error for the size of their input
- The documentation tells developers that inputs above certain sizes will be ignored

**Current Behavior**

Phone:
Client says **Input a valid integer** if the input is over 9 digits long (unsure about specific number).
Desktop:
Command is accepted, number is converted to string, and sometimes has off by one errors.

**Screenshots/Videos**

[Input](https://media.discordapp.net/attachments/584014133306064938/818076084494270474/unknown.png)
[Output](https://media.discordapp.net/attachments/584014133306064938/818076136457764874/unknown.png)

**Client and System Information**

Desktop:
Stable 78727 (b2380a5)
Host 0.0.309
Windows 10 64-Bit (10.0.17763)

Phone:
Android - 64.1 (1463)
 Comments: 
 Comment 0: > The interaction data JSON has the correct number as a number not a string

This would violate JSON spec. The best solution here would be to pass large numbers as strings.
 Comment 1: I wasnt able to find another issue in this github but I joined the API server and it seems to have been discussed 
![image](https://user-images.githubusercontent.com/24992458/110237846-1f003180-7f36-11eb-8e11-f46205855b6e.png)
So it might be js / discord.js related rather than API related.
Either way it might be nice to specify limits on integer inputs for slash commands.
 Comment 2: Specifically it's related to all parsers that consume valid JSON only. Java and JavaScript are among languages that cannot consume large numbers as numbers for one reason or another.

Number in JSON is the same as in JS - a 64-bit IEEE754 binary floating-point number. It has a 53-bit mantissa and that's where the precision limit comes from. If you puke large numbers into it as numbers and not strings, you will break compliant parsers.
 Comment 3: Should also point out: above is the same reason why IDs are encoded as strings.
 Comment 4: > Specifically it's related to all parsers that consume valid JSON only. Java and JavaScript are among languages that cannot consume large numbers as numbers for one reason or another.
> 
> Number in JSON is the same as in JS - a 64-bit IEEE754 binary floating-point number. It has a 53-bit mantissa and that's where the precision limit comes from. If you puke large numbers into it as numbers and not strings, you will break compliant parsers.

The limit on numbers in JSON is implementation-specific and accepting outside of what javascript allows does not make the JSON "invalid"

From [the rfc](https://tools.ietf.org/html/rfc8259#section-6) (emphasis mine)

> This specification allows **implementations** to set limits on the range
   and precision of numbers accepted.

Additionally, the [standard published by ECMA](https://www.ecma-international.org/publications-and-standards/standards/ecma-404/) also puts no such finite bit related bounds on numerics.

By this, it is entirely valid for Discord to choose to use a JSON (de)serialization method which does not have this issue or document how large numbers will be handled and at least handle them consistently between platforms.

 Comment 5: Yeah I'm fine if large numbers become strings but off by one errors, arbitrary digit limits that are inconsistent between mobile and pc should at least be documented. 
 Comment 6: would probably be best to show a "this number is too high" error; currently it just 400s if the number is really high
 Comment 7: I would also like a way to limit the size of the `INTEGER` type. If not to a specific max, at least to have something like int32 and int64. Maybe also a way to allow positive only and other reasonable restrictions. To support unbounded integers there could be another type that would send it as a string, but check that it's a valid number.
 Comment 8: Soon the client will reject your very large numbers.  Leaving this open to track the need for consistent limits cross-platform
 Comment 9: This was closed without further comment and it was stated this was being left open to track. This does not appear to have been fixed from minimal testing, was this closed inadvertently, is this thought to be fixed but hasn't been?
 Comment 10: The PR linked to his is merged, and thus it is assumed to be fixed. Post specific client reproduction steps and we can look again.
 Comment 11: > The PR linked to this is merged

This isn't publicly visible.

> Post specific client reproduction steps and we can look again.

I'll get a full set of details tomorrow as it is late here, I was still able to reproduce this on the stable windows client between when this was closed and when I posted.
 Comment 12: for me (on stable 81648 and canary 81777) it accepts 9007199254740991 but for 9007199254740992 and higher, it errors

![image](https://user-images.githubusercontent.com/11778454/114111313-96efad80-988e-11eb-9d31-f25b4ec86381.png)

 Comment 13: After a client update, no longer reproducible. Based on the timeline of when closed and when this was experienced, I suspect this is still technically possible to have issues with outdated clients and that it is not also validated on the server-side, but I can only infer that.
{'source': 'GithubIssues', 'repo_name_with_owner': 'discord/discord-api-docs', 'issue_id': 823890621, 'repo_stars': 3560.0}