Refactor large files into 1 file per class

[ben-xD]

The main objective of this PR was to move classes (& enums) that were in the same file into their own separate file. Once I did that though, each file had to be exported via ably_flutter.dart, and that was not clean, ably_flutter would have had to contain a list of all files. The solution taken was to create separate mini libraries with their own src directory, and export the source files from these packages. Then inside ably_flutter.dart, these libraries will be exported instead of each file. I took the opportunity to move files into more logical folders. Other small changes are present: typo fix, unused import removal, simplify test teardown code.

This is a pattern observed in the getx repo, though if another pattern is cleaner, please mention it.

This PR depends on #136

Notes for the future: There are additional patterns we can learn/ follow in the future, and this refactor would help with this. Another improvement we can make is to create an internal platform library, and not expose these in the public API like we do currently. It also makes the transition to a full Dart SDK in the future easier too. For example, renaming Rest to RestNative, and changing the public API to rely on an abstract factory. We can allow the user to use either the Native or the Dart SDK.

I was worried about public API changes, and I don't think this PR affects it. As long as only public APIs/ classes are added to the library files (e.g. ably_flutter.dart, push_notifications.dart, logging.dart). Theres more about this in the documentation: "Code under lib/src is considered private; other packages should never need to import src/.... To make APIs under lib/src public, you can export lib/src files from a file that’s directly under lib.", and on a stackoverflow answer.

[ben-xD]

Android 19 integration tests are failing, but after mentioning it in the stand up, we are actually dropping support for Android 19 and 20, raising minimum API level to 21. Please see Review JDK 7 and Android API Level requirements for Java SDK for more information.

[QuintinWillison]

Very difficult to review, given the size of change and amount of movement.

I think, in the interests of getting this landed sooner rather than later, it's best to rely on tests to indicate whether it still works. Also example app as proof of life.

[tiholic]

Looks good overall, few comments: