Re-entrancy detector + Control Flow Graph

[TilakMaddy]

Fix #313

• Control Flow Graph implementation
• State change after external call detector
• Emit after external call detector

Long version:

At the moment Control Flow Graph module exposes -

• Cfg::from_function_body(f: &FunctionDefinition)
• Cfg::from_modifier_body(f: &ModifierDefinition)

Returns a tuple (cfg, start_node, end_node)

The first argument is a cfg object that gives you access to the adjacency list representation of the control flow graph.
The second argument is used to point you to the place in the cfg where the function body's cfg start.

Those 2 things are used to build and traverse the control flow graph. In case you want to see the corresponding AST node, you can call cfg_node.reflect(context) on the CFG node. It will return ASTNode. Thanks to this, you can make use of existing ASTNode libraries and helpers.

Also attached to this PR are 2 reentrancy detectors plus an incorrect use of modifier detector that server as examples to see learn how cfg can be leveraged in various detectors

NOTE:
It constructs CFG from f's body only. It's not called Cfg::from_function by choice as that would involve decomposing the entire function (which involves resolving internal functions, resolving modifiers, etc). We don't have that ability yet

(Same logic goes for modifiers)

[TilakMaddy]

@alexroan Please review the detector test file, and see if you can break it ! Let me know if you can think of some edge cases not covered

[TilakMaddy]

Just realized I need to put a filter on the external calls to exclude the ones that are library calls because they are delegate calls and they can't reenter

UPDATE
Nope that wasn't true .. delegate calls can re-enter by this.XX() So I'm not making any changes :)