The old RegisterContextWinMiniDump stub is replaced with x86 and x64 implementations that derive from the common windows register contexts.
ProcessWindowsMiniDump grabs the WinAPI CONTEXT for each thread and stashes it in the thread object when building the thread list. The threads create the register context, stuffing in the saved CONTEXT.
New test ensures we can see the stack and registers for the (single) frame in the fizzbuzz minidump. (No variables or function names, since that inferior doesn't have DWARF information.)
You might also notice that I remove the thread names for MiniDump threads. Thread names are unavailable when port-mortem debugging Windows apps (since naming the thread requires having the debugger catch a special exception raised while the inferior is running).
I remember us being able to get call stacks higher than main. But now that I think about it I guess that's only true for live debugging since you have a physical copy of the module loaded in your process, and you can read it's EAT. In any case, this assumption probably won't be true anymore once we understand PDBs and symbol servers. Although at that point hopefully we'll have many more tests covering different scenarios.