Feature/theme spreads

[raveclassic]

Hi @javivelasco!
Firstly, my congrats on getting to 2.0 major!

Now about this PR.
Currently it's only possible to construct complex themes from more than two modules by composing themeable function which is far from convenient. Taking ES6 spreads into account this PR provides possibility to pass more than two arguments to themeable:

const a = {
  test: 'a'
}
const b = {
  test: 'b'
}
const c = {
  test: 'foo',
  foo: 'foo'
}
const expected = {
  test: 'a b foo',
  foo: 'foo'
}
const result = themeable(a, b, c)
expect(result).toEqual(expected)

Also it contains some refactoring of themeable function as it started to grow with type-check conditionals and setting of default values which is all pretty hard to maintain.

All tests pass, so take a look!

Update: I have found some TS typings added quite recently. Also themr build step is simple as hell - just a babel run. So I'd like to suggest switching to TS completely to be fully consistent with these typings and to enforce some real type checking. This is just a suggestion and I could prepare a simple PR with all code rewritten to TS. What do you think?

[raveclassic]

@TheSBros Hi, I've changed your initial typing of themr decorator to accept SFC and ComponentClass directly. I can't say for sure if I haven't broken something as it perfectly fits in my codebase instead of component: new(props?: P, context?: any) => React.Component<P, S> expression. Could you please review?

UPDATE: everything is ok with "@types/react": "^15.0.0"

[odensc]

@raveclassic If you look at #39 (comment) , there was a reason why I changed from ComponentClass.

It's currently late for me - but I will confirm if it still works in that situation tomorrow.

[raveclassic]

@TheSBros I see the problem now. Will try to handle it somehow.

[raveclassic]

I've managed to solve both problems by adding a second call signature type to decorator interface. Check it out.

[raveclassic]

Ok, I'm reverting typings changes because they are not related to initial PR. Only the part with themeable function is left and themr identifier can be a symbol now.

[raveclassic]

I'm sorry about this mess with PR :)
Finally, this PR solves both issues with accepting sfc in themr and extending themeable interface

[javivelasco]

Thank you both! I think it makes total sense. I'm not very familiar with TS though. I want to get into it but I'm lacking time to do so. It's a very nice contribution, congrats :)

[raveclassic]

@javivelasco Ok, I'll open a PR with a switch to TS when I have some free time. Surely build process migration will be completely transparent for you.