Added support for up to six runtime arguments

[ilyapuchka]

To register factories/instances it's now possible to use up to six runtime arguments. Clients can extend this number on demand.

@AliSoftware Please review it again. There are few changes that I want to note:

• I decided to remove method that registers factory that accepts tag as parameter, cause this case is covered with runtime arguments. Though I'm sure tags should stay, but they should be not used inside factories.
• Adding methods with generic arguments introduces ambiguity with resolve method that accepts only tag parameter, so I had to make tag parameter named.

[AliSoftware]

I was confused at first to see that we stored the factory closure in the DefinitionKey. I now understand that in fact you store the factory signature / Type in there, to store the expected runtime argument types.

So here we probably need to find a different name for this property, to make it less confusing with the other places when we use the term factory which expect an actual closure, while in DefinitionKey that's the closure type, not the closure itself.
I only understood that when I saw your let key = DefinitionKey(protocolType: T.self, factory: F.self, associatedTag: tag) here, seeing that you used F.self there.

Simply renaming this to factoryType or factorySignature or whatnot would make things clearer I think.

[AliSoftware]

Adding methods with generic arguments introduces ambiguity with resolve method that accepts only tag parameter, so I had to make tag parameter named.

I'm OK with that, but I think maybe we should make it more consistent throughout the API. Probably make the tag parameter always a named parameter everywhere (even on methods not using runtime arguments) would keep consistency while also avoiding people to confuse the usage between a call with the tag and a call with one runtime argument.

[AliSoftware]

@ilyapuchka Thanks for this promising work!

I only reviewed it directly on GitHub for now, looks OK so far but will have to take another look and open the code in Xcode to properly check it out and review it better. Will keep you posted.

[AliSoftware]

• Don't forget to add documentation in the README for those use cases. (I think the README can be improved and better organized to present the core concepts of Dip, btw)
• Don't forget the CHANGELOG.md as well
• Are you planning to add a Sample Project / Playground demonstrating usage of those Runtime Arguments in this PR, or do you plan to do it in a separate PR later?

[ilyapuchka]

Thanks for review, @AliSoftware, agree with all comments.
I was planning to add playground with all current features a bit later in separate PR.

[AliSoftware]

I wonder why sometimes Travis fails the compilation at the "▸ Touching DipTests.xctest" stage 😕
I just restarted Travis builds and they all pass now 👍 .

I promise I'll check this out tomorrow and hopefully we can finally merge it 😉

[ilyapuchka]

Done. Also fixed some documentation slightly.
Would be cool if we can merge it. There are bunch of other cool features waiting for their PRs =)

[ilyapuchka]

I think this thread may address Travis issue - travis-ci/travis-ci#4725

[AliSoftware]

Ah good point on the Travis Thread, will keep an eye on it

[AliSoftware]

Perfect 👌

Finally, I have time to merge this, sorry for the delay!

[AliSoftware]

(Note: you'll probably want to rebase your feature/playground on top of develop)