dyncom: Various cleanups to match coding style, no functional changes.

Allow focus on the Qt render widget

Rasterizer Optimizations

dyncom/armemu: Implement QADD8/QSUB8.

dyncom: Fix SMLALXY's instruction labels

They were erroneously labeled as SMLAL.

FileSys cleanup

dyncom: Implement UXTB16/UXTAB16

Execute the division-by-W for perspective-correct interpolation of
values in the clipper, moving them out of the rasterization inner loop.

Replace the loop-based texture address swizzling code by a bit-twiddling
implementation, providing a very small speed up. Also simplify
addressing code.

Move the computation of some values out of loops so that they're not
constantly recalculated even when they don't change.

Use a new buffer management scheme in the clipper that allows using a
bounded minimal amount of buffer space. Even though it copies more data
it is still slightly faster likely due to using less cache.

The triangle clipper was allocating its temporary input, output and work
buffers using a std::vector. Since this is a hot path, it's desirable to
use stack allocation instead.

Unused OutputVertex attributes were being left un-initialized. The
leftover garbage sometimes decoded as floating-point denormalized
values, causing fallbacks to microcode and massive slowdowns in the rest
of the rasterization pipeline even though the results were unused. By
zeroing the structure we ensure these attributes only contain harmless
zeros.

Frameskip

armemu: Simplify some instructions.

Qt: Citra crashes if disassembler pause button is pressed while no game is running. #172

vfp: Actually make the code somewhat readable

New Handle manager

Implement PKHBT and PKHTB on dyncom, fix on armemu

dyncom: Implement USAD8/USADA8

armemu: Fix underflows in USAD8/USADA8

This handle manager more closely mirrors the behaviour of the CTR-OS
one. In addition object ref-counts and support for DuplicateHandle have
been added.

Note that support for DuplicateHandle is still experimental, since parts
of the kernel still use Handles internally, which will likely cause
troubles if two different handles to the same object are used to e.g.
wait on a synchronization primitive.