Better design for host-originating signals

I am quite surprised by this provider. There are some surprising inversions happening here, for example, it depends on crate::shim in its signature.

I don't think the Signal sits well in shim, since the shim module is meant for traits that the shim must implement but there isn't a trait being implemented there.

Also, "shim should call" implies that a shim that does not call stuff is incorrect. This sort of requirement is exactly what traits are for, and thus the way the design should be is to actually have the shim implement a trait that probably looks like the following:

pub trait ConsumeSignal {
  fn consume_signal(Signal);
}

Then the platform can always invoke this trait, and the shim can make a decision of it wants to buffer things or not. If you need/want the "all in a group" behavior, then you can make the trait (instead of the above):

pub trait ConsumeSignal {
  fn consume_signals(&[Signal]);
}

Originally posted by @jaybosamiya-ms in https://github.com/microsoft/litebox/pull/690#discussion_r2874729698

Start with the discussion in PR #690 and inspect crate::shim and the Signal type to understand the current boundary. The issue names no files or tests; completion depends on resolving the proposed signal-consumption design and updating the affected implementation accordingly.