Use Go in a more idiomatic way

[daniel-abramov]

This is a result of working on https://github.com/matrix-org/waterfall/issues/120 which did not quite work as expected due to some bugs and issues with Pion.

So currently it's more a preparation to properly implement a https://github.com/matrix-org/waterfall/issues/120 and to get ready for https://github.com/matrix-org/waterfall/issues/117

This PR changes the following things:

• The way we work with the Go channels. It removes some helpers that we used to use in the past since they were not generic enough and their implementation would not work as expected if used as a generic channel implementation. We also use unbounded channels more than before that simplifies the backpressure between the router and the conference. The only part that is left that does not look super idiomatic is pkg/channel/sink.go (might get improved in the future).
• We now use a bit more idiomatic package structure, i.e. this PR removes the usage of a common package as it seems to be an antipattern that is used to overcome Go limitations and which ends up having everything that does not belong to other packages.
• Prepare for https://github.com/matrix-org/waterfall/issues/117

Note that there is one significant change in the behavior: currently, the router process the messages from the Matrix SDk and sends them to the conference via an unbounded channel. This means that if one conference freezes, it will affect all other conferences! It's not a problem for now since we only primarily use a single conference and the conferences should never freeze (so it helps to check if our implementation is sound), but ideally we probably need to get the buffer back for the conference, otherwise we won't be able to make them all independent.

[daniel-abramov]

I think this looks good, but this is a huge PR with a lot of unrelated changes, making it very hard to review. Moving things out of common, in particular, feels like it doesn't belong here.

Yeah, sorry, perhaps the common part should have been moved into its own PR.

I tried to separate changes by commits, so it's easier to review the PR by checking each individual commit as one commit did one single thing (I tried to rebase them before creating a PR so that it's easier to follow the logic and the changes). I.e. if you review it by commit, I think it should be more manageable as they are mostly small.