aom: fix problematic range enforcement for --sout-aom-cpu-used

this almost entirely reverts 0f9bb18b,
leaving just the updated larger upper range bound.

there were two problems with that change:
 1. it is problematic to use such library version detection in plugin
    descriptors.
 2. it is pointless to have introduced just this one very specific warning
    and clamping, while ignoring the existing fact that for the usage mode
    of good-quality the value should be 1-5, while for realtime it should
    be 6-8, now 6-10 with libaom >= v3.2.0. (and as of a few commits back,
    7-9 for mode all-intra). either we should clip and warn fully, or not
    bother and let libaom just accept/reject/clip as appropriate.

implementing clipping/warning handling for the different appliable ranges
just adds unnecessary extra burden to keeping this module up to date with
libaom changes.

it is problematic to use library version detection in the plugin descriptor
to set the corresponding upper bound, since the generated config set built
by executing the descriptor function is saved in a cache to make loading
vlc more efficient. this may work fine for builds that bundle libaom as a
contrib, if updates re-build the plugin cache, but does not work fine on
systems where libaom is a separate system library, which could at any time
be upgraded or downgraded without a rebuild of the vlc plugin cache, which
could leave the bound too low or too high depending upon the version
installed at the time of loading vlc.

let's just specify the new upper bound and leave it at that. if someone is
using an older system library and happens to use a value of 9 or 10,
then we can just let libaom clip the value or reject it.