Fix #2715

[tgriesser]

Turns out that #2542 was a bit of bigger change than anticipated because it also required that NOW / CURRENT_TIMESTAMP also have the precision specified to work correctly. So for now we're going to make it:

1. Opt-in, you must specify the timestamp precision for mysql in order to enable this
2. Doesn't work with .timestamps() - I personally find it better to specify timestamps manually, the extra line saved is not worth the added complexity given the current confusing options in that method.
3. Only for mysql - although PostgreSQL supports a precision option, it's probably a bad idea since it defaults to the current, which is why I didn't add this option for that driver.

In the future I'd like to revisit to get a better API here / warn / correct for invalid behavior, because I do agree it'd be good to have millisecond precision built-in... but for now I'm not sure it's worth the backward incompatibility, given that a lot of projects probably have something like:

t.timestamp('created_at').defaultTo(knex.raw('CURRENT_TIMESTAMP'))

So to use it in mysql:

knex.schema.alterTable(t => {
  t.datetime('column', 6).defaultTo(knex.fn.now(6))
  t.timestamp('column', 6).defaultTo(knex.fn.now(6))
})

@ricardograca I'm going to put this out as a patch release since it didn't actually ship properly in 0.15 given the client flag option, and then the inconsistencies were discovered in 0.15.1.