Swiftyinsta: Road to `2.0`

Hi Stefano,
I must say thanks to you for helping me and contributing this library, there is nothing more than your participation makes me happy.
This is a good idea, jumping to version 2.0 with good feature and changes.
I was thinking about implementing some extra functions which helps user to deal with library easier,
features like receiving:

• High Quality Media [video or image]
• Low Quality Media [video or image]
• Image Thumbnail for media
• Statistics functions(calculating total likes, comments, ...)
• More flexible delay feature(editing it in run-time, or switching it on-off) with easier ways.
• and etc....
  which saves a lot of time for users, these are just ideas.
  Because the library is growing up by passing the time, the library definitely needs documentation.
  we definitely needs to fix naming conventions, because there are very mistakes. and I like the UserReference idea that was nice one.
  development branch is needed as well.
  we should invite other users to contribute and sharing ideas here to make next version more powerful.
  Thanks again.
  Regards.

1. easier permission handler, dropping the Singleton model and all the .shared, allowing users to run multiple accounts at the same time [I might start working on this today or tomorrow, if it's ok]

I've started working on this. The actual authentication mechanism is in place, I just need to finish rewriting every single method for all the different handlers (😱), and then all it takes is making the same changes to Siwa.

What I've done so far:

• APIBuilder, HttpSettings and RequestMessageModel are gone. Now you instantiate directly APIHandler with some Settings taking (optional) delay, queues, device (automatically updating the User-Agent) and session (URLSession) parameters.
• Nore more *Handler protocols. There was no actual point for them. Every *Handler can now be called through the APIHandler instance (UserHandler is .accounts, FeedHandler is .feeds, etc.), they're lazy properties and they're specific to the instance itself. I've done the same for HttpHelper and PaginationHelper (a.k.a. PaginationHandler in 1.*). This removes all the code duplication where every single method had to be rewritten for APIHandler, and it means "multitasking" with multiple APIHandlers for different logged users.
• Authentication is now handled by one single method in the APIHandler instance: authenticate(with request: Login.Request, completionHandler: escaping (Result<(Login.Response, APIHandler), Error>) -> Void), where Login.Request is an enum that can either take a SessionCache item (which is similar to 1.* SessionCache), and it's used for "logging back in" and with Siwa (in the future), or a LoginWebView (a.k.a. InstagramLoginWebView) — and it's so much simpler than it is now. Literally one call and you're done. This removes all the code duplication between Siwa and SwiftyInsta: if you want "headless" authentication, use Siwa and pass the sessionCache, otherwise use the _web view_ in SwiftyInsta.
• Every single method accepting either a _user_ pk or username now takes a UserReference item instead.

I count on finishing everything by tomorrow, and then I could push it to development for further testing. I'm genuinely super excited 💪
I'm looking forward to knowing your thoughts and opinions.

The changes seems to very good, development branch added as well.
I'm working on a list of features and tools such as Logger and etc.
And about Authentication, this new method supports all 3 kind of authentications?

1. Private API Login
2. Web Login
3. Siwa

I'm done with all the changes above. I'm testing it for a while and then push a _pull request_.

And about Authentication, this new method supports all 3 kind of authentications?

Right now it supports _web login_ and Siwa (theoretically since Siwa uses *.shared, so it will need to be updated, but I'm planning on doing it asap — meaning right now, in the meantime, you can only test it with _web login_). I feel like the username + password authentication provided with SwiftyInsta was not up to par, tbh. And since you've done an amazing job for it in Siwa, I really feel like it can be dropped from the main library (but it's just my opinion).
I strongly believe that users wanting to do username + password authentication should do it right from the start (i.e. with Siwa), without overcomplicating everything else, and duplicating code bases. Again, just my opinion.
It can just as well be added again 😊

(I tried to fix typos, and mistakes along the way when I spotted them, but I feel like some methods — e.g. the weird POST ones, might still not work as intended. They didn't in 1.* and they might not in 2.0. Idk)

@sbertix @canaksoy
More ideas? any update?

Support for watchOS, tvOS and macOS

I was thinking about multi OS support #61
I'll try and work on it later.

Cleaning responses

• High Quality Media [video or image]
• Low Quality Media [video or image]
• Image Thumbnail for media
• Statistics functions(calculating total likes, comments, ...)
• More flexible delay feature(editing it in run-time, or switching it on-off) with easier ways.
• and etc....

About this, I was thinking… why not rationalizing the way responses are presented to the user?
Instead of returning directly the decoded file (which could become like a raw property), why not returning a cleaned struct, with date already formatted, images with different qualities (like you said), stats embedded into them… etc.

e.g. instead of pushing MediaModel like it is, returning something closer to…

public struct MediaModel: Codable {
    /// `MediaModelJSON` would be equal to current `MediaModel`.
    public let rawResponse: MediaModelJSON

    // Accesories
    public var pk: Int! { return rawResponse.pk }
    public lazy var date: Date! = { return self.rawRespone.takenAt.flatMap { Date(timeIntervalSince1970: $0) }}()
    /* etc */
}

Yes this is a good idea, we should edit models anyway. some of them are missing a few properties and there are many duplicates between models useless protocols and ....
We should definitely improve models and the way they represents data to user.

What about enforcing syntax rules through swiftlint?
Easy to add support for it to Travis CI, but actually super long to change the entire codebase accordingly.
But it should be worth it, imho.
What do you think? @TheM4hd1