Implement symbolic branch tracking in core, add new fork event

[offlinemark]

This PR implements tracking of symbolic branches in each State (specifically state.context['branches']). It does this using a new event: forking_state. Similar to will_fork_state, forking_state fires when a state fork occurs, however it fires once for each individual state forked, being passed the specific value that has been concretized. will_fork_state fires once on a general state forking event, being passed the collection of all concretized values. This is unsuitable for tracking symbolic branches per state because the State the event handler has access to during will_fork_state is the parent state, and not a child state. For tracking symbolic branches, we want to only modify the specific child state.

Points of discussion and controversy:

Whether we should track symbolic branches in the core, versus requiring users to do this.

I think this is general enough and useful enough functionality to compute in the core and have available to users "for free".

The name of the event: forking_state.

I'm open to suggestions for other names! forking_child_state, ...

The introduction of State._init_context.

I thought it would be useful to have a central place where all the entries of state.context are initialized, versus them largely being initialized ad hoc in various places in hooks in manticore.py. Initializing entries of state.context here allows code that uses state.context to be less cautious about whether a entry actually exists or not. For example:

manticore/manticore/manticore.py

Line 558 in 5ad18e7

state_visited = state.context.get('visited_since_last_fork', set())

manticore/manticore/manticore.py

Line 568 in 5ad18e7

state_visited = state.context.get('visited_since_last_fork', set())

manticore/manticore/manticore.py

Line 601 in 5ad18e7

state.context.setdefault('visited_since_last_fork', set()).add(address)

Currently only context['branches'] is initialized here, but the idea is to eventually port other usees of state.context in the core to initialize those members here.

[feliam]

Unnecessary lock

[offlinemark]

Summary of discussion in chat regarding locks for posterity

• no calls to publish need to be wrapped with a self._lock (the fact that will_fork_state publish above did this was a bug)
• all callbacks execute in separate worker threads, so there is only process unsafety considerations if they access shared data. shared data refers to the global executor context (Executor._shared_context, accessed through Executor.locked_context` (see executor._fork_state_callback for an example)
• if a callback accessed global shared data, it is the callback's responsibility to use the aforementioned lock when accessing it
• currently only callbacks at the executor level even have access to the shared data. a deeper callback at the state, platform, cpu level for example could not even do process unsafe things if it wanted to