avcodec/bitstream: replace qsort with AV_QSORT

Commit 3a0a2f33a6 claims large performance
advantages for AV_QSORT over libc's qsort. The reason is that I suspect
that libc's qsort (at least on non LTO builds, like the typical FFmpeg config)
can't inline the comparison callback:
https://stackoverflow.com/questions/5290695/is-there-any-way-a-c-c-compiler-can-inline-a-c-callback-function.
AV_QSORT has two things going for it:
1. The guaranteed inlining of qsort itself. This yields a negligible
boost that may be ignored.
2. The more serious possibility of potentially allowing the comparison
function to be inlined - this is likely responsible for the large boosts
reported.

There is a comment explaining that this is a place that could use some
performance improvement. Thus AV_QSORT is used to achieve that.

Benchmarks deemed unnecessary due to existing claims about AV_QSORT.
Tested with FATE.

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

libavcodec/bitstream.c

@@ -30,6 +30,7 @@
 
 #include "libavutil/atomic.h"
 #include "libavutil/avassert.h"
+#include "libavutil/qsort.h"
 #include "avcodec.h"
 #include "internal.h"
 #include "mathops.h"
@@ -333,7 +334,7 @@ int ff_init_vlc_sparse(VLC *vlc_arg, int nb_bits, int nb_codes,
     }
     COPY(buf[j].bits > nb_bits);
     // qsort is the slowest part of init_vlc, and could probably be improved or avoided
-    qsort(buf, j, sizeof(VLCcode), compare_vlcspec);
+    AV_QSORT(buf, j, struct VLCcode, compare_vlcspec);
     COPY(buf[j].bits && buf[j].bits <= nb_bits);
     nb_codes = j;