Implementing deaths

[erik-rosenstrom]

This PR implements the effects of a dead symptom status. This involves disallowing future plans that are scheduled to happen for dead individuals and removing them from setting membership.

Changes

• A death module was created with event subscription to listen for dead symtpom status progression.
• Upon death the alive person property is set to false, they are removed from setting membership, and if they are infectious when they die, the directly transition to the recovered infection status.
• A death context extension was created with the method to ergonomically check the alive status. This context extension includes a lightweight wrapper on add_plan called add_plan_if_alive that checks if the person is alive before executing the callback.
• An additional method was added to the settings context extension to remove the person from setting membership. Their itineraries are maintained in case additional analysis on a dead person's itinerary is required.
• Tests were add to the death module to ensure all functionality of death occurs how we expect.
• Checks were add to multiple places in the infection_manager and infection_propagation_loop modules to check if the person is alive before proceeding

Open Question

Should the add_plan_if_alive be used for all plans? Even those in the symptom status manager that execute before a person dies?

Additional Resource

A design document for deaths in models can be found here