Restrict pydantic requirement to < 2.0

[jwodder]

We can update the code to use pydantic 2.0 after it comes out.

See #176.

[codecov[bot]]

Codecov Report

Patch and project coverage have no change.

Comparison is base (b310e3e) 97.71% compared to head (1542d74) 97.71%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #177 +/- ## ======================================= Coverage 97.71% 97.71% ======================================= Files 17 17 Lines 1751 1751 ======================================= Hits 1711 1711 Misses 40 40 ``` | Flag | Coverage Δ | | |---|---|---| | unittests | `97.71% <ø> (ø)` | | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=dandi#carryforward-flags-in-the-pull-request-comment) to find out more. Help us with your feedback. Take ten seconds to tell us [how you rate us](https://about.codecov.io/nps?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=dandi). Have a feature suggestion? [Share it here.](https://app.codecov.io/gh/feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=dandi)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[yarikoptic]

Sad part of the story is that then pip would likely just to install some prior release of dandi-schema if some newer "bad" pydantic would already be installed, so overall this specification is good to have but is not really even a workaround. Looking forward, I guess we better indeed strive to keep such specification in the future to prevent "known to break something next major release" from being installed. Meanwhile will also add release label and merge.

[jwodder]

@yarikoptic

Sad part of the story is that then pip would likely just to install some prior release of dandi-schema if some newer "bad" pydantic would already be installed

A (somewhat drastic) way to prevent this from happening would be to yank (not delete!) all older dandischema releases from PyPI, which would prevent pip 22.0+ from installing those versions unless the user specifically requested the older version with ==. If someone then tried installing this latest dandi-schema in an environment in which pydantic 2.0 had already been installed, I believe pip would fail without installing anything.