Improving performance of original dav1d video decoder

Summary

@another, @mstorsjo, @gramner Introduction I noticed a very clickbait bounty, I initially realized that company's original task was not to overtake implementation, but to advertise that Rust is 5% slower than C. Whether she actually pays or not is another matter. The main thing for Prossimo was to make a fuss that the current rav1d implementation was only 5% slower, so that the general public would think that the language was the same in speed. I also noticed contributor's blog who tried to optimize rav1d, but he didn't go beyond 1%. Actually, I solved his problem, he came out at 0%. CHICKEN JOCKEY Well, first thing I decided to do was look dav1d at the memory organization in CPU cachelines, and I noticed that dav1d really consumes large structures. It is desirable to have structures of 64 bytes or less in size, it is easier for C/C++/C# compiler to process them. Since it's very difficult to recycle structures, I solved problem more simply. At first, out of habit, I aligned, but I couldn't align because some of the data was bulging. And I remembered about taming enum to strict values so that it fits into 1 byte and it can be conveniently manually aligned. I made maximum values for each enum, and strictly specified a size 1 byte for them. I also realized that int in structures is a waste and decided to compress it to a uint16_t (2 bytes). If you know how to use pahole, then you can view the object files in release, debug, non-optimized debug, and so on. By default, C/C++ compilers do not change the size of structures until the programmer himself specifies the packing or alignment attribute (keyword). The compiler also sometimes does not optimize enum itself to 1 byte if the strict flag is -fshort-enums, but I had to manually align to optimize the space, so I did this optimization in advance. Also, don't expect the compiler to change int to uint16_t itself. Briefly changes This PR will decrease costs copying, moving, and creating object-structures only for common 64bi...