vorbisenc caps are ordered improperly

Submitted by LRN

Link to original bug (#590361)

Description

First structure of the caps should be the preferable one. Vorbisenc however specifies its first structure as
gst_caps_append_structure (caps, gst_structure_new ("audio/x-raw-float",
"rate", GST_TYPE_INT_RANGE, 1, 200000,
"channels", G_TYPE_INT, 1,
"endianness", G_TYPE_INT, G_BYTE_ORDER, "width", G_TYPE_INT, 32,
NULL));
Because of that some elements (namely a52dec) pick first structure to work with, thinking that vorbisenc prefers mono (and because they are able to convert anything to mono, making it compatible).
If vorbisenc have had its 8-channel structure first, 7-channel structure second etc, any element would have picked the highest channel count compatible with its natural channel count. For this to happen elements (namely a52dec) should iterate over structures in the caps until they find a structure that is compatible (can be used without upmixing). Elements should not use gst_structure_fixate_field_nearest_int() with structure's channel count and natural channel count, because this way they would pick 8-channel structure as compatible, if natural channel count is less than 8 (fixating to natural channel count), which is OK in terms of channel count, but may lead them into picking wrong channel layout designed for 8-channel audio (the exact result depends on how gst_audio_fixate_channel_positions() would work in situations when channel count does not match channel-positions).
There's also a channels=[9,256] structure, and it should be the last one.