Implement Polymer Collection keys

So, I have implemented polymer collection keys instead of the use of custom id's. What does this mean practically:

The good stuff

• You don't need to (and can't) specify an id-property attribute anymore when you're just using <paper-datatable>
• This solves some not so obscure bugs where reloading actually doesn't reload anything, as the id stays the same, so the system won't regenerate the row.
• Complex data manipulations on items should now work auto-magically (still need to do some testing and the testing isn't high prio as it's probably something nobody will ever wish to do, but yeah xD )
• It's simply more robust and less prone to error
• id-property is now a valid attribute on <paper-datatable-card> which makes a lot more sense as the previous version was using a bug to function. You can now also find a selectedIds property on <paper-datatable-card>
• There is now a selection-changed event
• There are a lot more selection manipulation functions exposed on <paper-datatable>

The 'bad' stuff

• There is no selectedId and selectedIds property on <paper-datatable> anymore. Instead we now have a selectedKey and selectedKeys property which returns Polymer internal keys. selectedItem and selectedItems should still work. In general I think you will want to use those last two, so maybe I will make the selectedKey and selectedKeys properties private at some point.
• Originally the data-source API provided two retrieval methods, one through id's and one directly. The version through id's was there as it would in the feature allow me to implement an actual WeakCache. I still might consider doing this at some point, but I am quite happy with the performance all considered, so I guess this was a typical example of premature optimization.
• I dropped support for the time being again for adding new items on the fly. It was too hacky and didn't even work that well. If you already use it, just drop me a line and I will give it another go. Still planning on re-implementing this, but just not now.

Backward incompatible changes

I have explained this to some users of this component already, but right we're still in the 0.x.y range which means in semver language that

Anything may change at any time. The public API should not be considered stable.

The upside of this is that I can make a public API which is as solid as possible, but that's the downside of using alpha/beta releases. Still though, it's starting to look pretty good in my opinion, so I think this might have been the biggest change I still had to make (though no doubt I will make some small changes still).

Upcoming backwards incompatible changes

Only one I can think off right now is that I am going to change sort-property and sort-direction from <paper-datatable> to <paper-datatable-column>

Small stuff

Not even sure what's in this release, but just want to make sure all small fixes are tagged as a separate release before I commit and push a big change

Small stuff

0.3.1

List of demos

Quite a lot of neat stuff has happened, including Edge support and styling

0.3.0

Make tap in checkbox cell select row as well

Some small changes

0.2.1

alpha -> solid alpha

Far too many backwards incompatible changes

It's for the good of the element, but it sucks that I have to make them... I dropped the first argument of get.

Better events and probably lots more

0.1.4

cell tap now includes all the good stuff xD

Lots of new documentation!

0.1.3

type

0.1.2

README update

0.1.1

Improve Firefox support and clean up demo