* Remove type/UNIX* and type/ISO8601* from frontend

* Set effective-type and coercion strategy when syncing

these values will most likely only be available when using tests, as
metadata is very unlikely to have this. As far as I can tell the
toucannery apparatus is the only bit that has this. Its quite
artificial. I'm not sure if this is a good idea.

* :type/UNIXTimestampSeconds and type/ISO8601DateTimeString out of type

remove the coercions from the type hierarchy. This brought up a
strange issue that has been present for a while: all liquidbase
migrations run and then all data migrations run. They are not
interleaved. This allows for the following scenario:

- data migration migrates all X values to Y in version 26
- liquibase migration migrates all Y values to Z in version 28

But these are not run in version order, but all liquibase migrations
are run and then all data migrations are run. If you were on an old
version for a while, you could end up with Y values even though the
liquibase migration which comes "after" the data migration turns all Y
values into Z values.

This impacts this change because a data migration in this way:
- liquibase changesets 287, 288, 289, and 290 remove all 'type/UNIX*'
and 'type/ISO8601*' semantic types. These were in 0.39
- data migration `migrate-field-types` added in 0.20.0 was looking for
special_type's of "timestamp_milliseconds" and migrating them to
"type/UNIXTimestampMilliseconds".

Since the liquibase runs before the migrate-field-types, it's possible
for a 'type/UNIX*' semantic type to reappear. And since these were
removed from the type system it would fail validation and blow up. In
this case it actually can't happen since the field its attempting to
migrate (special_type) no longer exists. But since the migrations are
not interleaved this problem still exists.

* whatever prettier

* Appease the machines

* Restore the unix and iso semantic types to hierarchy

migration tests still use these
`(impl/test-migrations [283 296] [migrate!] ...)`

A few things in tension: the field requires valid semantic_types,
these _were_ valid semantic_types until v39.

* Remove old "coercion" semantic types

* Migrate the v20 version semantic types for unix epoch

* Time travelling migrations

these target v20 and v29 which at the time they existed had a column
special type not semantic type. But these run after all of the schema
migrations, not interleaved, so they will have a semantic_type not
special_type when they actually run even though they target v20 or v29
data. strange world

* add migration's new checksum