Fix shadowing-function detector and enhance inheritance-graph

[Xenomega]

This pull request aims to resolve #165 . It fixes the shadowing-function detector and extends the inheritance-graph printer.

Changes:
-Fixed an issue where the shadowing-function detector would return all inherited functions (even if not shadowed).
-Added an internal directory under detectors to house detectors which are not used for vulnerabilities, but as helpers throughout the program (such as for the inheritance-graph printer).
-Renamed the argument for shadowing-function detector to shadowing-function-internal
-Updated inheritance-graph printer to highlight all function collisions (shadowing + shadowed functions, not just shadowing).
-Updated inheritance-graph printer to consider modifier collisions (not just functions).
-Updated inheritance-graph printer to highlight collisions via C3 linearization (and added a relevant internal detector to help with detection of all c3 linearization function collisions).

Note: Unimplemented functions and their later implementations will not count as collisions currently (and will not be highlighted). This can easily be changed if desired.

[montyly]

Some notes:

• After some tests, I am not sure we should highlight the shadowing functions. It makes the use of the printer a bit ambigious (ex: you might think that a function is shadowed, while its the shadowing function). We could use another color, but it's not necessary good to have too many code colors. Another solution is to write the canonical name of the shadowing function next to the shadowed function's name, any thoughts?

• We could do the same for the state variables. Right now, the derived contracts show all the state variables, while it could only show the new ones (and in red the shadowed ones, as it's probably a bug)

• My first idea of having detectors that are not 'calleable' from the cli command was a bad idea. We can probably just create a slither.utils.inheritance module with functions that provide the same info

[Xenomega]

For simplicity in distinguishing commits, the following changes have been since @montyly 's above post:

• Internal detectors were removed and logic was moved to slither.utils.inheritance_analysis. This provides functions to obtain all shadowing/shadowed function pairs.
  • detect_direct_function_shadowing(contract) will obtain all shadowing via direct line of inheritance for a given contract.
  • detect_c3_function_shadowing(contract) will obtain all indirect shadowing through C3 linearization.
  • detect_function_shadowing(contracts, direct_shadowing=True, indirect_shadowing=True) combines the results from each into pairs which more simplistically state what is shadowed, and what is shadowing. This is used to obtain clean results for the inheritance-graph printer.
• inheritance-graph was modified to only highlight shadowed functions.

TODO:

• Currently detect_function_shadowing returns overshadowed pairs for c3 linearization that may contain duplicates, while the same definition cannot actually appear more than once.
• Add state variable shadowing helpers to inheritance_analysis, plug it in to inheritance-graph.
• Determine how to connect shadowing vs shadowed functions (such that it is easy for users to read: coloring can become difficult to understand and not provide verbose-enough output for the user to distinguish what collisions are ocurring).

[Xenomega]

For documentation:

To this point, all TODO's are complete (save for the last). Additionally:
-If a contract has multiple inheritance, edges will be numbered in the order of declaration.
-Fixed a bug where special output formatting for state variables of type "Contract" would never be reached.

[Xenomega]

This PR is ready for review now. The final behavior for inheritance-graph is as follows:

• Edges are numbered according to order of inheritance.
• Variable shadowing will be shown in red.
• Direct function shadowing will be shown in orange.
• Additional information about indirect shadowing via c3 linearization will be shown in an additional text box at the bottom of any affected node.

Example:

Other supporting changes/bugfixes are detailed throughout this thread.