Create driver init graph

[bSchnepp]

A graph of lambas should be used to handle startup initialization, so "board-specific" drivers that are currently in use which don't actually have to be tied to the device or board directly can be separated, and possibly even attach unit test cases to them. The primary and immediate use case for this is to properly detect the timer on the board, instead of simply assuming it's the generic system timer.

This should be achieved with a graph of lambas, and done in 3 passes: one for driver initialization to set the device up at the mmio address needed, another pass for the actual driver startup routine, and a final pass for any cleanup the driver needs to do. Each of these routines should be reentrant, and can maybe be called more than once.

These functions should be assembled based on the device tree when startup happens, and then executed in a depth-first order.

[bSchnepp]

Something that should probably be investigated is to look for better ways to abstract memory.
A particular problem is that some drivers as they are now simply poke into the physical address of the system without any real management for them. This is particularly the case with the GIC and serial drivers.

A driver init graph should go over and optionally allow the definition of a structure, such as

struct MemoryTag
{
    void *PAddr;
    void *VAddr;
    
    template<typename T>
    T *Get(UINT64 Index) 
    {
        return &((T*)PhysicalAddressToKernelVirtual(this->PAddr)[Index]);
    }
    
    template<typename T>
    void Set(UINT64 Index) { ... }
};

class MemorySpace
{
public:
    MemorySpace();
   
   MemoryTag &GetTag(); // ...
private:
    MemoryTag *Tags;
    Process *Owner;
};

so that the behavior of MMIO can be more easily isolated and tracked down.