Generic Lobby improvements

Ideas for improvement:

• Poll for changes to state so that refreshes are not required. (done in #510)
• Option to automatically remove room if all users leave the room (made the default behaviour in #276)
• Add optional unique name check
• Add optional limit for rooms (will disable ‘create room’ button if rooms number reached limit)
• Provide ability to customize ui when waiting for an API call (i.e. loading state)
• Rename gameInstances to rooms (easier to understand). (done in #406 and then re-renamed to matches in #704)
• Show leave button even if the game is ready to play. (done in #510)

EDIT: Design document by @flamecoals: link

[nicolodavis]

My thinking was that we just provide the REST API (which can be consumed in many ways). In addition to that, we also provide a default lobby implementation (that can be styled). If someone wants to build a completely different lobby, they can go ahead and build that on top of our REST API.

What we should be focusing on is making our existing lobby generic enough that people won’t see the need to re-implement it.

However, I can see some value in providing a client-side abstraction if we want to hide the communication between client and server (for example, if we want to start using sockets). Maybe we should revisit this idea once our lobby implementation is starting to do complex things like that.

[vdfdev]

@francoijs Thanks for the help! Approved all your suggestions. I will probably do the first PR soon on this.