Add Javacord as a compliant library

[Bastian]

This pull request (re)adds Javacord as a compliant library. The library got removed (commit c4a4783), because it didn't properly handle ratelimits (see #108) back then due to not being actively maintained.
The latest version is a complete rewrite which properly handles ratelimits (delay actions using the headers to not cause 429s) and is 100% feature-complete besides voice.
These are the ratelimit-relavant classes, if you want to check:

• RatelimitManager.java
• RatelimitBucket.java
• RestRequest.java

The result would look like this without hitting any ratelimits:

for (int i = 1; i <= 12; i++) {
    channel.sendMessage("Ratelimit Example #" + i);
}

[Bastian]

Small update: I have reworked the ratelimit handling for the next version 3.0.1 a little bit.
The code is now better readable and global ratelimits are shared across different shards, as long as they are in the same runtime.
You can view it in the development branch:

• RatelimitManager.java
• RatelimitBucket.java

Some explanations how ratelimits are implemented:

• Every bucket has 0-1 threads running that are responsible for executing the request
• If a new request gets queued, it checks if there's already a thread running -> If not, it starts a new thread (/uses one from a thread pool) (line 66 and 76)
• Inside the thread, before sending a request, it checks if the current bucket is ratelimited (lines 87-102)
• The getTimeTillSpaceGetsAvailable() method considers both global and bucket-specific ratelimits (lines 113-121)
• The ratelimit information gets updated in the handleResponse() method (lines 160-204)
• To share global ratelimits accross shards, they are stored in a static HashMap with the bot's token as key and the reset timestamp as value (line 15)
• Additionally, to compensate an incorrect clock of the client, the date header is used to calculate the offset (lines 212-230). If we ever hit a 429, the offset gets recalculated.

If you don't only care about proper ratelimit handling, but also about the "quality" of the library itself, here are some additional information about Javacord:

• We have plenty of tutorials in our wiki https://javacord.org/wiki/ to help users
• The rewrite has over 1200 commits and over 62.000 lines of code and we worked on it for nearly 1 year
• We publish to Maven Central
• There's already an active community of users and contributors and our Discord server with >500 members.
• There are clear contribution guidelines and code conventions to help both new and existing contributors: CONTRIBUTING.md
• We automated a lot of repetitive actions with our CI-server (https://ci.javacord.org/). It automatically releases a new version with a single button press, publishes snapshots for every commit, validates commits and pull requests (does it build?, does it violate code conventions?, do unit tests fail?, ...), publishes JavaDocs at https://docs.javacord.org/ ...

We put a lot of effort in this rewrite, and I would be very grateful, if you consider readding Javacord.