Remove setuptools_scm

[pganssle]

For the 3.0.0 release, I think we should remove setuptools_scm. So far this hasn't really saved us much effort, and on multiple occasions it's caused trouble. The upsides of manually maintaining a __version__ string (or equivalent):

1. Version information is in the repo itself, so a snapshot of any given version is self-contained.
2. Removes a build-time dependency
3. The code in the repo will match what is actually distributed more closely.

Downsides are:

1. We lose the nice property where each revision gets its own version string
2. We might forget to bump the version (might be something we can check with GA?)

I think setuptools_scm was also doing stuff about maintaining the MANIFEST.in that I didn't realize, and I'm not sure I'm entirely comfortable with.

[mattmauriello]

@pganssle , thank you for looking in to this. So that we can make plans internally, when do you expect a patch version would be published? we have a fair amount of patching and deploy to do to work around this, but if you expect a patch available shortly, we may be able to wait for that.

[pganssle]

@mattmauriello Like an hour? Maybe 2?

[mattmauriello]

@pganssle , we see the new package version, and it's resolving our issues where we've tested so far. Really appreciate your work and the quick turn around here, it was a life saver.

[wimglenn]

You can see my comment in the packaging.python.org guide for several more downsides. What happened with python-dateutil 2.9.0 release is a great case-study on the sort of difficulties that the convention of having a __version__ string directly in the source code can cause.

Thank you for the prompt fix/post-release, and big +1 to removing setuptools_scm