omxil: Don't claim to support vorbis decoding

The only vorbis omxil decoder I know of, OMX.google.vorbis.decoder,
requires the bitstream to be altered in two ways compared to what
we send currently. The extradata/codecconfig needs to be split with
xiph_SplitHeaders and headers 0 and 2 need to be sent in individual
buffers, and each payload packet needs to have an extra 4 byte trailer
containing the number of samples in the ogg page (look for
kKeyValidSamples in libstagefright/OMXCodec.cpp in android).
p_block->i_nb_samples doesn't contain the necessary value, but we
can provide -1 instead.

All in all though, the vorbis bitstream/packet format used in the
OMX.google.vorbis.decoder component seems to be pretty unspecified
and hacky, not a properly standardized one. (Although, if a hw
manufacturer were to include a vorbis decoder of their own, they'd
probably make it use the same bitstream format as google's, to make
it easy to plug into the framework.) I doubt there is a hw decoder
component available at all, even less so a decoder that would be
significantly faster than our normal built-in sw decoder, so there
is little point in trying to map this codec via omxil.