Allow angle brackets in DOI validation (#513)

[rhigman]

Fixes #513.

[rhigman]

@ja573 note the run-migrations failure - the migration was successful locally. I think this is because (as previously discussed) Diesel interprets the migrations as being in the wrong order (strict alphanumeric):

rh@obp-rh:~/code/thoth/thoth-api$ diesel migration list
Migrations:
  [X] 0.0.0_diesel_initial_setup
  [X] 0.1.0
  [X] 0.10.0
  [X] 0.11.3
  [X] 0.11.7
  [X] 0.2.0
  [X] 0.2.11
  [X] 0.3.0
  [X] 0.3.5
  [X] 0.4.1
  [X] 0.4.2
  [X] 0.4.5
  [X] 0.5.0
  [X] 0.6.0
  [X] 0.7.0
  [X] 0.7.2
  [X] 0.8.0
  [X] 0.8.11
  [X] 0.8.3
  [X] 0.8.5
  [X] 0.8.8
  [X] 0.8.9
  [X] 0.9.0
  [X] 0.9.16
  [X] 0.9.2
  [X] 0.9.6

If run-migrations starts with a clean database and tries to run 0.0.0, then 0.1.0, then 0.10.0, etc, the 0.11.7 migration will be the first one to fail as it is the first one to try and alter a table which wasn't created in 0.1.0 (reference). Our local machines' databases already have all of the pre-0.11.7 migrations, so just that one is run and it's successful.

[ja573]

@ja573 note the run-migrations failure - the migration was successful locally. I think this is because (as previously discussed) Diesel interprets the migrations as being in the wrong order (strict alphanumeric):

rh@obp-rh:~/code/thoth/thoth-api$ diesel migration list
Migrations:
  [X] 0.0.0_diesel_initial_setup
  [X] 0.1.0
  [X] 0.10.0
  [X] 0.11.3
  [X] 0.11.7
  [X] 0.2.0
  [X] 0.2.11
  [X] 0.3.0
  [X] 0.3.5
  [X] 0.4.1
  [X] 0.4.2
  [X] 0.4.5
  [X] 0.5.0
  [X] 0.6.0
  [X] 0.7.0
  [X] 0.7.2
  [X] 0.8.0
  [X] 0.8.11
  [X] 0.8.3
  [X] 0.8.5
  [X] 0.8.8
  [X] 0.8.9
  [X] 0.9.0
  [X] 0.9.16
  [X] 0.9.2
  [X] 0.9.6

If run-migrations starts with a clean database and tries to run 0.0.0, then 0.1.0, then 0.10.0, etc, the 0.11.7 migration will be the first one to fail as it is the first one to try and alter a table which wasn't created in 0.1.0 (reference). Our local machines' databases already have all of the pre-0.11.7 migrations, so just that one is run and it's successful.

Ok, in that case just change the name of the migration to something that will ensure it runs at the end. When we release v1 I'm planning on combining all migrations into a single one and start anew with migration names that follow the right structure anyway, so it's fine to change the convention now to avoid current problems