Allow mercury footer/header update based on content

[obrusvit]

This PR modifies the mercury Frame so that it's able to hold a function pointer into a Footer updating function and Header updating function. This is useful so that the Footer or Header can react to the changes in the footer's content without making additional wrappers around Frame.
This functionality is applied to ShowShareWords, ConfirmFido and it also adds a footer page hint functionality to RemainingShares window which didn't make it in #4142 . Another candidate might be address_detail.rs

In addition, the PR removes some unused code from the Frame.

For future reference, other approaches were considered for the update functionality:

• passing a reference of the content to the Footer which would be something like &dyn InternallySwipable. This is difficult to do because of lifetimes.
• making a an update function in frame which would update the footer if the content was InternallySwipable. This would require "specialization" feature which is not stabilized
• using a closure Fn instead of a function pointer fn. This is difficult because Frame must implement Clone and Fn is not Sized and we do not have a smart pointer wrapper.

[obrusvit]

The new footer in RemainingShares window:

• one page only
  

• more pages
  

cc: @Hannsek @lapohoda

[github-actions]

core UI changes	device test	click test	persistence test
T2T1 Model T	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
T3B1 Safe 3	test(screens) main(screens)	test(screens) main(screens)	2724
T3T1	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
All	main(screens)

[mmilata]

Possibly unnecessary, PageHint already contains logic to display empty strings under single-page content (footer.rs:444).

[obrusvit]

you're right, addressed on rebase

[matejcik]

maybe not in this PR but ... how about flipping the dependency relationship and making frame a member of whoever wants to be doing the footer updates?

[obrusvit]

maybe not in this PR but ... how about flipping the dependency relationship and making frame a member of whoever wants to be doing the footer updates?

@matejcik If I understand your suggestion correctly, that's what was happening before and it leads to creating more and more structs around the components and implementing Component for them with considerable code duplication.

struct SomeComplexScreen {
  frame: Frame<Something>,
  footer: Footer,
}

impl Component for SomeComplexScreen {
  fn event(...) {
    frame.footer.update_instruction(...);
    ...
  }
}

It seems to me cleaner to create those screens right away using regular components for the flow, now with the ability to change their content.

Frame::new(title, Something::new()).with_footer(...).register_footer_update_fn(some_fn);

I'm willing to discuss further.

[matejcik]

@matejcik If I understand your suggestion correctly, that's what was happening before and it leads to creating more and more structs around the components and implementing Component for them with considerable code duplication.

what I have in mind is removing frame.inner.
this inverts ownership: instead of Frame<Something>, you would have Something { frame: Frame }.

you need impl Component for Something anyway, so this impl would also pass events to the Frame as appropriate.
but you don't need a SomeComplexScreen around the whole thing, because Something is already that

[github-actions]

legacy UI changes	device test(screens) main(screens)