Explore improvements to appups via static analysis

[bitwalker]

Right now Distillery generates appups by statically analyzing the differences between the set of BEAM changes between version A and version B, if a module has changed, it is upgraded appropriately based on it's contents. If a module is added it is loaded/started appropriately, and likewise stopped/unloaded for modules which are removed.

The problem with the current state of affairs is that state changes between one version and the next require one to implement code_change (or one of it's related counterparts) to modify the state accordingly. This is necessary when such state changes are complex, or require knowledge not amenable to static analysis. However I would like to explore what state changes are amenable to static analysis, and attempt to improve the happy path for upgrades. One thing which interests me is the possibility of storing git ref information somewhere in the release, such that comparing one version to another can also inspect the actual changes made in git to determine if a change was a rename (such as moving a struct from one namespace to another, or changing a struct field's name, but not it's contents). Obviously this wouldn't work if the project isn't source controlled in Git, but since I suspect there are a great many that are, this presents an opportunity to take advantage of that knowledge. Additionally, with the right architecture, the source of the difference information could be isolated, such that similar information could be generated from another source control system.

The output of the analysis could be a code snippet (something like "hey, you didn't implement code_change for this GenServer, so drop this snippet in the module and you're good to go"), or perhaps a warning (such as "hey, the state changed in this GenServer but your code_change callback doesn't handle it properly), or perhaps some other avenue which allows us to deal with it automatically or appropriately inform the user.

This issue is meant to gather thoughts and encourage discussion on what the options are, the edge cases/downsides, and what problems people are having with hot upgrades; if we can make improvements using static analysis, we can convert specific techniques into concrete issues for development.