schemas: Rename the UpdateSchema

I'm about to introduce a schema to list updates, so I'm renaming this
one first to avoid any confusion.
schemas: Get the Builds class out of the schema

This will make it reusable by other schemas.
schemas: Rename the splitter

I'm about to reuse it for other schema nodes, it's really not specific
to builds.
schemas: Validate the bugs in a nicer way

This requires a modification to the splitter, though.
schemas: Add a schema to validate update listings

It only contains the critpath thing for now, we'll add the rest to it
bit by bit.
views: Plug the new schema to the update listing

This immediately has one obvious benefit: the critpath validator becomes
completely unneeded and can be removed. :)

The relevant unit test must be changed slightly for the wording of the
error message, but all in all, it makes things simpler.
schemas: Add the type item to ListUpdateSchema

Contrarily to the critpath case, the custom validator we had can not be
removed this time.

However, because the schema itself already ensures that the passed
parameter is a proper value, then the validator becomes much simpler:
it only needs to transform the string into the enum item.
schemas: Add the request item to ListUpdateSchema

Just like for the type, this makes the validator drastically simpler.

The view and the unit test are both adapted to the change.
schemas: Add the status item to ListUpdateSchema

Just like for the type, this makes the validator drastically simpler.

The view and the unit test are both adapted to the change.
validators: Generalize validation of enums

Now that we use schemas for both saving and listing, the way we validate
the enums became identical in both cases.

Making the enums optional in validate_enums allows the listing
validators to be completely dropped.
schemas Add the submitted_since item to ListUpdateSchema

I'm dropping the whole custom date validator in the process, which means
we lose one thing: dates in the future are not considered errors any
more.

However, I don't really see the point for our purpose: trying to list
updates submitted after a date in the future will just not return any
update, which is fine really.

Plus, the colander stuff returns a timezone-aware (UTC) datetime object,
but datetime.now() returns a timezone-naive datetime object, so the two
can't be compared.

Python < 3.2 makes it a pain to create a timezone-aware datetime object,
so I'd rather avoid it as the feature is not really needed. (for now)
tests: Make sure the date will always be in the future

I don't want to see this unit test start failing when we reach that
date. :)
schemas: Add the releases item to ListUpdateSchema

This is one more case where the validator is simplified by the use of a
schema: the releases are already splitted, we only need to check that
they exist in the database.
validators: Properly validate releases

We shouldn't mark invalid releases as validated.
schemas Add the user item to ListUpdateSchema

This does not gain us much, other than adding the item to the schema for
consistency.
views: Reorder the update listing filters alphabetically

We're starting to have a lot of them, and others are still coming. This
should make the code slightly more readable.
Filter update listings by packages

This adds the required schema node, view filtering, and unit tests.
Filter update listings by bugs

This adds the required schema node, view filtering, and unit tests.
tests: Add a CVE to the test update
Filter update listings by CVEs

This adds the required schema node, view filtering, and unit tests.