adjust to Pungi 4 nightlies and fedfind 2
    
    This is a fairly minimalist approach at handling Pungi 4 and
    fedfind 2.x. Since we don't have a clear idea how milestones
    will work yet, I decided not to throw out the versioning scheme
    and rename all the wiki pages, at least not yet. Instead this
    is a bit of a stealth approach. All page names remain the same,
    there are no incompatible interface changes. The biggest issue
    we have is it's no longer possible to map 100% reliably from
    a nightly event version to a fedfind nightly compose, because
    the event version (page name) doesn't indicate the compose
    respin.
    
    We use a dose of fudge to handle this. NightlyEvent now has an
    optional `url` argument, which should be a Pungi 4 compose
    location; the idea is that when creating a NightlyEvent you
    can pass the compose URL to indicate precisely which compose
    you want the event to be for. There's also a new `Wiki` method,
    `get_validation_event_url`, which accepts a single argument -
    a Pungi 4 compose URL - and parses it to come up with a
    wikitcms-style version, then returns an appropriate event
    instance for the event version and URL. The idea is that relval
    will grow a fedmsg consumer for creating nightly events; any
    time it sees a 'compose complete!' fedmsg it can get an event
    instance for that compose using the URL provided by fedmsg, then
    decide whether it makes sense to actually create the event.
    
    You can still instantiate a NightlyEvent in the old way, with
    just release/milestone/compose. To try and get the correct
    fedfind release instance, if the event doesn't exist it'll
    wind up using fedfind guessing to pick exactly which of that
    day's composes to use (fedfind will find the latest completed
    one, if there is one). If the event *does* exist, there is an
    awful awful hack which tries to parse the compose URL back out
    of the event's download page. If that doesn't work we just fall
    back on fedfind guessing and hope it happens to pick the same
    compose the event was created for. In practice, once a nightly
    event is created we rarely do anything with ff_release anyhow,
    so it's not actually that big of a deal.
    
    Long term, once we know how milestone composes are going to
    work with Pungi 4, we might want to do a more fundamental change
    to Wikitcms and wikitcms, but I don't want to start doing that
    in advance of the necessary information. *Ideally* I'd like to
    get the hell off Wikitcms and onto a more sane manual validation
    test system by then.
    
    We also adjust to fedfind 2, which provides productmd-style
    image dicts rather than fedfind 1-style Image instances. We
    move the 'image scoring' stuff here, fedfind no longer does
    that.