(Pushed a fix for the formatting, was an extra blank line)

I want to note that this PR is in service to tracking issue #1043.

Now, before HAVE_WORK was a VolatileCell

This seems to be important for the compiler to elide writes to static mutables that are not read within the same crate. Or at least was. So it was a hack, and I don't think we should need it if it's a member field.

In the spirit of our last weekly call, I think it's important to describe how these changes impact interfaces elsewhere.

I think given that #1043 is a tracking issue, it's good to work on these kinds of incremental changes, but would also just be good to document what someone getting an external port or capsule up to speed with a recent Tock version might need to change.

In this case, I believe the only required change is in the board configuration, where instead of calling kernel::kernel_loop(...), you now must first initialize a statically allocated instance of the Kernel struct and call kernel_loop as a method:

let board_kernel = static_init!(kernel::Kernel, kernel::Kernel::new());

board_kernel.kernel_loop(&tm4c1294, &mut chip, &mut PROCESSES, Some(&tm4c1294.ipc));

the arguments to kernel_loop don't change.

These changes have the Kernel struct stored with an explicit 'static lifetime. That's reasonable since it's probably a reasonable choice to statically allocate it anyway (we want these structures to tax sections of the binary such that an overflow will be caught by the linker, so not on the stack), but I wonder if this is a hard constraint, or if the lifetime can be parameterized.

In general, my intuition is that parameterizing lifetimes will give us more flexibility to eventually take out shared static variables (this is an intuition, I don't have a good argument for why that is).

I think it's fine to leave this as-is, if we convince ourselves that clients of this interface (board main.rss) will mostly likely still statically allocate, and in any case any relaxation of the lifetime constraint will still be compatible with static allocation (I think it is).

I added a CHANGELOG file with the changes I think matter for external projects. I'm approving with this addition, but leaving the final word on this to @bradjc. I'm also marking this P-Significant, which gives it another day for someone to raise the alarm bells.

Looks good to me :)