[RFC] [dead diopter] Rewrite of dead using diopter

This is a minimal proof of concept for a diopter-based dead. (I took some parts of didead.py but left others out). Everything works in didead2.py: generating code, filtering interesting cases, reductions, bisections. The goal of this PR is to iterate and "smoothen" diopter's API.

I did not include any database related code as it was too intertwined with the logic in didead.py and it would have taken me too long to figure it (and sqlalchemy) out. I think it needs a bit more massaging and modularization, so let's figure out the core dead/diopter first and then we can iterate on that.

Instead of building a full blown command line tool, I suggest treating dead as a library that sits on top of diopter that let's us write full blown end-to-end pipelines in <50 lines of python code. And once we have this, writing a cmd tool should be trivial.

Here are a few observations:

The reductions checks API is horrible. Everything must be encoded as a string and if something goes wrong there are no useful error messages. The bisector has a much nicer API to solve the same problem. I think it makes sense to come up with a more generic one and use it in both the reducer and the bisector.
dead.checker is a bit too restrictive is some cases (e.g., requiring that all attackers can eliminate a marker). We can have a much more generic checker, e.g., one that can do cross-compiler checks, signature based ones, etc
We need some kind of global context/config (e.g., my DiopterContext suggestion) where a lot of standard paths/objects are stored. E.g., the location of gcc's and llvm's repos should be known most of the time without ever needing to specify them. If there's a need to use a non-standard location then ~/config/diopter/diopter.json (or similar) can be modified. Other tools, e.g., dead can also register their defaults in the same directory or json file.

DeadCodeProductions / dead

[RFC] [dead diopter] Rewrite of dead using diopter #43