provide separate release types for server and non-server deliverables

Change the 'std' release type to 'python-server' and add a
'python-pypi' release type for deliverables that are published to
PyPI.

Separate the release job validation from the validation of release
version numbers and other settings to make the logic clearer.

Add a new function to determine the release type for a project, either
by checking the explicit value or guessing.

Update the unit tests that relied on 'std'.

Remove a unit test that tested a code path that has been removed.

Change-Id: I704ec75fec61ecb6ee379239a5fa8612cb01b426
Signed-off-by: Doug Hellmann <doug@doughellmann.com>

README.rst

@@ -397,10 +397,14 @@ The top level of a deliverable file is a mapping with keys:
 ``release-type``
   This (optional) key sets the level of validation for the versions numbers.
 
-  ``std``
+  ``python-server``
     Default: Enforces 3 digit semver version numbers in releases and allows
     for common alpha, beta and dev releases.  This should be appropriate for
-    most OpenStack release requirements.
+    most OpenStack component release requirements.
+
+  ``python-pypi``
+    Like ``python-server`` but requires the jobs to publish the component
+    to the Python Package Index (PyPI).
 
   ``xstatic``
     Allows a more flexible versioning in line with xstatic package guidelines