MMIO: Cleanup Mapping class by using templates instead of macros.

The MMIO mapping interface was using lots of macros before to use the same code for different MMIO register sizes. This branch replaces the macro usage with templates.

Macros aren't a particular modern way of using C++ to begin with, but in this case I think using templates instead of macros indeed makes the code a lot more readable. Additionally, I was able to clean up the interface a lot because the C++ overloading restrictions don't affect templated code.

For what it's worth, I'm not sure if

    template<typename Unit>
    struct HandlerArray
    {
        using Read = std::array<ReadHandler<Unit>, NUM_MMIOS / sizeof(Unit)>;
        using Write = std::array<WriteHandler<Unit>, NUM_MMIOS / sizeof(Unit)>;
    };

    HandlerArray<u8>::Read m_read_handlers8;
    HandlerArray<u16>::Read m_read_handlers16;
    HandlerArray<u32>::Read m_read_handlers32;

    HandlerArray<u8>::Write m_write_handlers8;
    HandlerArray<u16>::Write m_write_handlers16;
    HandlerArray<u32>::Write m_write_handlers32;
is any cleaner than

    std::array<ReadHandler<u8>, NUM_MMIOS / sizeof(Unit)> m_read_handlers8;
    std::array<ReadHandler<u16>, NUM_MMIOS / sizeof(Unit)> m_read_handlers16;
    std::array<ReadHandler<u32>, NUM_MMIOS / sizeof(Unit)> m_read_handlers32;

    std::array<WriteHandler<u8>, NUM_MMIOS / sizeof(Unit)> m_write_handlers8;
    std::array<WriteHandler<u16>, NUM_MMIOS / sizeof(Unit)> m_write_handlers16;
    std::array<WriteHandler<u32>, NUM_MMIOS / sizeof(Unit)> m_write_handlers32;
Opinions on that? (having written this in comparison, I got to say myself that the second version is probably better)

For reference, the version of this code living in current master is

    #define HANDLERS(Size) \
    std::array<ReadHandler<u##Size>, NUM_MMIOS / sizeof (u##Size)> m_Read##Size##Handlers; \
    std::array<WriteHandler<u##Size>, NUM_MMIOS / sizeof (u##Size)> m_Write##Size##Handlers;
    HANDLERS(8) HANDLERS(16) HANDLERS(32)
    #undef HANDLERS
I'm 100% confident that this will generate optimal assembly code for this function after optimization. However, I'm not so sure if it will do things like preventing loop unrolling etc. If you want, I can perform some testing on this.