New experimental transact() method

While migrating my project to IndexedDB from syncronous WebStorage API,
I found it hard having to always pass transactions or tables around to
library functions and class methods.

Testing now a new method that can create a transaction without having to
pass the table instances to the callback. Instead, db.[table] will
always work no matter if being within a transaction or outside.

The plan is to replace the current transaction() method with this new
method and either depricate Dexie.transaction() or change
Dexie.transaction() to work as the new version while still leaving it
backward compatible.
New transact() method merged with transaction()

The existing transaction() method now works as the new transact()
method. This will make migrating to the new way of handling transactions
easier.

A difference with db.transaction() is now that instead of throwing when
user tries to access db.[table] directly in the transaction scope, we
now allow it. In fact I plan to change the documentation to promote this
way of coding as the way to run code in transactions.

Since the method is still backward compatible we still have the chance
to revert to the old way of handling transactions if we decide to.

In this checkin, the new method Dexie.vip() and the property
Dexie.currentTransaction is moved to be static instead of bound to db.
This is because they dont need to be bound to db instance since they
work towards Promise-specific data.
Updated unit-tests
Bugfixed and migrated Syncable&Observable to new transaction method
Version 0.9.8 alpha with updated tests and samples

This commit contains the following changes:

* New transaction() style fully functional and is now the encouraged way
to use the db.transaction() method. Wiki docs will soon be updated.

* Rewrote all unit tests to use the new transaction style
(db.transaction() without callback arguments since they are no longer
needed). Note that the transaction() method itself is backward
compatible but it does not require the caller to use the provided
arguments anymore. I want to encourage not doing that because in a
future version the callback arguments will be removed. Instead use
db.[table] directly everywhere. The only exception from that is
Version.upgrade() since you are working on old version's tables with
different schemas.

* Rewrote all samples and addons to use the new transaction style.

* Support for sub-transactions. This is a natural consequence that we
need to support if users should be able to write transaction blocks that
should be reusable from within an outer transaction block.

* New unit tests for sub-transactions and error handling in sub
transactions.

* Bugfixes in the upgrade / populate framework

* MultiModifyError renamed to ModifyError (MultiModifyError could sound
like there was some kind of race condition or simultanous modifications
taking place, which is not the case with this exception).

* Bugfix: ModifyError.failedKeys did not always contain the last failed
key.

* Collection.keys(), eachKey(), firstKey() and lastKey() now also works
on primary keys.