Taking ownership of menu in runner

[ryan-summers]

This PR refactors the Runner to take ownership of the root menu. This enables the menu to be created on an ad-hoc basis (i.e. not at the crate root) to be handed to the Runner without lifetime worries.

The impact is that we can't keep references to the menu internally, so we have to traverse the menu throughout operation. Open to some suggestions.

For an example as to why this is needed, refer to https://github.com/quartiq/stabilizer/pull/813/files#diff-f0b20facc8d3d2dfccda7199e70cb8af5ba9255d80e1d35fdd950dc6a2d567a3R30

I'm trying to build a generic "Serial Console Settings Manager" that uses menu for providing the UI for settings management

[thejpster]

The Runner object takes a &Menu so that the Menu object can live in .rodata in an immutable static. This change will mean the menu gets copied on to the stack, and could potentially use 100s of bytes (I'm guessing - I haven't checked).

Maybe we could change the runner to take AsRef<Menu>? Then it will work with either Menu or &Menu, like those Standard Library APIs that take AsRef<str> or AsRef<Path>?

[thejpster]

Wait, no. I checked and my OS_MENU is only 24 bytes. Then I remembered that the menu items live in their own slice, so the Menu is just two Option<function pointers>, a &[Item] and a &str. 6 words, so 24 bytes. All checks out.

So this PR seems fine then.

[thejpster]

I think struct Menu will need to be clone, otherwise if it's a static you can't get it into the runner.

[thejpster]

Added a impl Clone for Menu

[thejpster]

Sheesh, I haven't looked at this in ages. Have tidied up a bit.