JDA getter hierarchy abstraction

[Branzz]

Pull Request Etiquette

• [x] I have checked the PRs for upcoming features/bug fixes.
• [x] I have read the contributing guidelines.

Changes

• [x] Internal code
• [x] Library interface (affecting end-user code)
• [x] Documentation
• [ ] Other: _____

Closes Issue: NaN

Description

Summary

Adds a unifying superinterface for the common JDA getter.

Reasoning

There were 54 cases of "JDA getJDA()" getters. That has been reduced to 34, 32 of which were direct default/non-abstract implementations of it, and the other 2 of which were still abstract and were left because their documentation left extra details about its specific sub-implementations, i.e. it could throw an exception. Almost all of the previous abstract implementations had inconsistent variations of exactly the same documentation, which has now been unified. This change would remove a lot of duplicate code and documentation and lets developers not have to write the same documentation and/or change it slightly for this method, opting to just implement the FromJDA interface instead. This will very unlikely affect any end-user code. And, this project is not foreign to this pattern, with its ISnowflake interface already.

Notes

This could also be applied to the common Guild getter, which had 81 uses, 25 being abstract. getChannel and getUser/getAuthor had too few use cases to do a similar thing.

[Tais993]

Would personally name the interface "JdaContainer"

"FromJda" sounds like a method fromJda, gives me the impression I can create the entity, from JDA.

[Branzz]

@Tais993 Yes, maintainers feel free to change it to whatever name makes sense :). I actually wasn't too sure on the one I picked, it was supposed to be as if it was already created "from that jda" instance you can get. JdaContainer probably works better.

[MinnDevelopment]

I'm not a huge fan of introducing interfaces for a single method. This is really kind of strange to do and results in very complicated type definitions. Inconsistent wording in the documentation isn't really a problem either, since they all mean the same thing at the end of the day.