Make python bot internals less complex

[CameronAavik]

Part of the reason that we switched over to a custom python implementation was that we wanted to react quickly to Slack API changes that break things as the official APIs are slow to react.

I'm worried that our current implementation of the wrapper uses too much python magic that is very beginner unfriendly.

In addition, as we move towards rate limiting, we are going to need to have every API call asynchronous (since it is processed on a queue, needs to be handled like promises) so the rethink of the internals should be addressed at the same time.

I propose that:

• We remove the APIMethodProxy
  • Instead we just have the API class which has a bunch of async methods, this means we don't need bot.run_async either.
  • There is no harm in using strings for the endpoints rather than hacking around with __getattr__
• Remove the underscored_getters
  • They break type hinting in PyCharm
  • Not really sure what they do either/why we can't just use the properties themselves
• Extract out UQCSBot stuff into more classes
  • It does way too much and it's really complex, we should reduce the amount of things it does
• The architecture of the internals is documented in a wiki page
  • All design decisions of the architecture should be justified
  • Most decisions have been made because of limitations of the Slack API, so someone new to the project won't know about those

[TRManderson]

We actually don't need to have every API call async FYI, can just implement them using normal blocking primitives

[mitchmcdee]

I'd definitely like to discuss this more at some point. #282 is somewhat relevant

Realistically, I wouldn't be against the idea of removing the majority of our asyncio in the interest of beginner friendliness; which might make ideas like #286 more important (for user feedback during blocked calls)

[TRManderson]

Yep, I'm fine with removing most of our async in favour of beginner friendliness.