Fix font:raleway version mess

[alerque]

This font is a mess because the upstream sources are all over the place.
Each new version seems to show up on a different distribution channel,
usually without a version number or source code, and people have been
just guessing what they are. There are several upstream source
repositories posted by different people that have worked on the family
but they don't even all match each other.

The most coherent clues come from the changelog posted at Google Fonts:

https://github.com/google/fonts/blob/master/ofl/raleway/FONTLOG.txt

There it is clear that some version scheme has been attempted. The
personal sandbox of one of the designers also suggests the version
3.x being the last official release.

https://github.com/impallari/Raleway

There he also has some ongoing development work tagged as 4.x, but as of
yet it is incomplete and considered unreleased.

This tries to straighten the version scheme processing so snapshots are
ignored, devel versions are so tagged, and the 1.x, 2.x and 3.x releases
are actually assumed to be correct.

Note also Raleway Dots is a separate font with a different upstream
release cycle not actually versioned along with Raleway.

[AMDmi3]

Great work, thanks!

Let's just simplify this a bit by not taking nix version 2016-08-30 into account - there's global rule which handles these. E.g. ".*20[-0-9]{6,8}" → ".*20[0-9]{6}". Also you could use snapshot instead of ignore. It's the same thing, but with less vague name (see #43).

[alerque]

Simplified as suggested.

[alerque]

Catching the delimited dates (2016-08-30→20160830) is nice, but what about when upstream authors forget a leading zero in a dated snapshot number? Such is the hapless case for fonts:raleway which one chap packaged as 0.0.2016830. Should I fix this specific instance somehow or is there a generic way of handling such slip ups?

[AMDmi3]

This is a rather special case so it makes sense to have an individual rule for it.