Implement soc-manager-service

[kurtjd]

There were a few suggestions for what the soc-manager-service should handle, but for several of them I couldn't come up with abstractions I felt satisfied with after thinking about them and experimenting.

For now, this PR keeps it simple and focuses on proper power state transitioning and power regulator rollback in event of failure. In its current state it is more of a library than a service as there are no associated tasks, but that will likely change in the future.

Power state transition
I followed the docs from here for my understanding of valid power state transitions. Offline it was discussed that the embedded-power-sequence traits be renamed to match ACPI power state names, but in this context, I think it makes sense to keep them as-is. The S0, S3, etc terminology reflects a state, but we can view the embedded-power-sequence traits as state transitions which are aptly named IMO. Also just added a simple standard interface for allowing multiple listeners to power state changes (since currently platforms are just rolling their own slightly different but ultimately the same implementation for this).

Rollback
Made a simple data structure backed by a heapless vec which acts as a stack that regulator operations can be pushed to. In the event of failure, or explicitly called rollback, this just allows us to reverse every prior regulator operation. The idea is this will be used in the embedded-power-sequence trait impls for a SoC (the docs contain an example of how I pictured it being used).

Other suggestions folks offered and things I need to think about more:

• The service should check that temps aren't too hot and there is enough power for a requested state. For power, I couldn't see a way to actually get that information currently. Does power-policy service offer this in some way? After a glance I didn't see anything.
• The service should monitor watchdog/prochot/reset lines. Offline it was suggested user provide a callback closure that the service can call when one of these lines goes active, but playing around with it, closures are challenging when it comes to async and how they capture variables, and I couldn't yet think of a way to provide much value here that a user couldn't just get from spawning a simple task that does, e.g.:

loop {
    watchdog_rst_pin.wait_for_low().await;
    // Handle it here
}

so will need to think about this a bit more.

• It was also suggested the service should incorporate some security management stuff, but I'm not familiar with this area yet so will need to research further.

Resolves #685