Move MatrixClient._sync method to MatrixClient.sync

[non-Jedi]

• Docstring for _sync needs to be written.
• Make sure the _sync method signature is what we want to expose to users
  long-term.
• Rename _sync to sync.
• Deprecate listen_for_events.

Some discussion of this plan on #173.

[ghost]

I think we really need a top-level design plan for the API (or at least MatrixClient's interface) before going ahead with this. What should the whole interface look like? What are the flows? It should have answers to questions like: Do we want users to have access to sync, or should that be internal? Why/why not?

TL;DR Why are we doing this again?

[non-Jedi]

I haven't sat down to writeup a full design doc of any sort for this sdk; that's
true. I'm just trying to make small incremental improvements where I see them.
Having a method listen_for_events that does literally nothing outside of
calling another (private) method makes no sense and just adds cognitive overhead
to anyone trying to grok the sdk's design. Especially when sync is more
descriptive (in matrix land) of what the method does than listen_for_events.

Given that this sdk is still pre 1.0.0, we should make these incremental (but
breaking) improvements now so that we have less cruft to deal with when we need
to do this kind of indirection to maintain backwards compatibility later.

EDIT: I guess what I'm saying is that I've got a vague vision in my head only of
a consistent design for this sdk, and I'm opening issues to document bits and
pieces of where the sdk deviates from that vision as things come up. If someone
else wanted to actually write down a plan for the sdk's design that was
internally consistent, I would gladly drive the project in that direction
instead of my vague vision.

[ghost]

I guess my points are:

• Nobody can help you implement your vision so long as it's only inside your head
• Your vision is lost to the project should you decide to give up maintainership.
  (Which happened at least once already. Different people driving the project into different directions every year is not good for the project.)
• Given the two points above, being short on time makes it all the more important to have a good design doc that people can work towards long-term.