add initial markdown output for memory maps

[hydrolarus]

This adds a "host binaries" cargo workspace that contains a binary that generated markdown documentation from memory maps.

This should probably be made more configurable, but I want to know what the requirements are in the first place.

So, any ideas or input @lmbollen @martijnbastiaan ?

[martijnbastiaan]

This looks very nice! I've got a few questions/comments:

• The generated types are confusing to me, they're neither Rust or Haskell types I think. Is it possible to just print both in different columns?
• Can you make an index.md linking to all devices?
• I think it would be pretty cool to show the device as a tree, including interconnects. Is that possible? (Not for this PR probably.) I think markdown allows <li> and friends.

[hydrolarus]

The generated types are confusing to me, they're neither Rust or Haskell types I think. Is it possible to just print both in different columns?

Yeah I wasn't sure what to go with, maybe we should just make the call to say it's always Haskell since that's the source of truth?

Can you make an index.md linking to all devices?

Right now I just go through every memory map and just generate it as it is, I don't do de-duplication like I do for the other code generators because I thought for documentation you don't care about deduplication?

I could run the deduplication pass anyway display non-shared devices differently in a index.md?

- [`Uart`](..)
- [`Timer`](..)

Devices with conflicting definitions across hardware instances

- `GatherUnit`
  - [`SwitchDemoPe`](..)
  - [`ScatterGatherTest`](..)

Opinions?

I think it would be pretty cool to show the device as a tree, including interconnects. Is that possible? (Not for this PR probably.) I think markdown allows

and friends.

That's definitely possible! I could add that in this PR too, I don't think there's too much hurry for this? There's no plan how to make it work with mdbook yet anyway, so I can work on this :)

[martijnbastiaan]

maybe we should just make the call to say it's always Haskell since that's the source of truth?

We can start with that, yes. I figured you want to make memmap-generate source agnostic, so I suggested listing both -- but we can do that later. For now at least picking one and being consistent makes sense.

Right now I just go through every memory map and just generate it as it is, I don't do de-duplication like I do for the other code generators because I thought for documentation you don't care about deduplication?

Makes sense to me! I'm sure we'll form opinions when we actually start using it.

There's no plan how to make it work with mdbook yet anyway, so I can work on this :)

@lmbollen has ideas