Hide revision hashes from user-facing messages

[colinhacks]

Before

$ edgedb migration create
Created dbschema/migrations/00003.edgeql, id: m1yh4d3dmfghpbidcnh3jf3flusvznborapmb54blv5mloiqzuzsia
edgedb migrate
Applied m1yh4d3dmfghpbidcnh3jf3flusvznborapmb54blv5mloiqzuzsia (00003.edgeql)

After

$ edgedb migration create
Created dbschema/migrations/00003.edgeql.
$ edgedb migrate
Applied dbshcema/migrations/00003.edgeql.

[tailhook]

I find hashes informative and debuggable. E.g. when some migration applied on the production and then file was mistakenly changed by rebasing, it's easier to find out that different revision was applied to production by looking at the log.

We discussed accepting prefixes of the migrations instead of full-length ones. But that requires some thinking of how short they should be and when to make them more long and what to do with conflicting prefixes. The fact that we have two sources of the revisions (files and database) checking for conflicts may severely complicate some of the workflows, I think.

[tailhook]

Note to myself: actually --to-revision support with unique prefix is implemented. So I think we can get away with something like 14-char prefixes (i.e. 12 chars of hash + "m1"), to get reasonably-unique identifiers.