git and hg: ignore tags that can't be normalized to version numbers

[avirshup]

trafficstars

As discussed in #229, when determining the latest tag, it would be ideal to use a general, unambiguous test for whether or not to ignore a given SCM tag.

For instance, a commit marked with tag v2.1.0a4 should, of course, be considered version 2.1.0a4. A commit tagged only with my.awesome.tag should be ignored (and definitely NOT parsed as major='my', minor='awesome', patch='tag').

After dealing with #229, I'll add a more complete spec here for how this test should work. My preference is to delegate to an existing tool that normalizes version strings according to PEP440.

[reece]

I've recently started getting errors like AssertionError: cant parse version default/1.2.6.dev1 in several repos.

(I believe this tag was generated by hg-git (unconfirmed). In any case, I did make the 1.2.6.dev1 tag, but not with the default/ prefix.)

Regardless of the cause, it seems that setuptools_scm does not deal gracefully with tags that look like version numbers but aren't. Currently, it appears that all tags with a . are deemed to be version tags (in hg.py:get_latest_normalizable_tag()), which is clearly too permissive.