Uko/Renraku: One Model to Rule Them All

This version brings many usability improvements and implementation optimizations.

Now each rule has a setting entry that can be used to disable (or enable) it for a complete image. Of course, as any setting rule bans can be persisted for the future images. <img width="902" alt="screen shot 2017-08-16 at 01 50 30" src="https://user-images.githubusercontent.com/817441/29360831-07be9496-8285-11e7-9cfc-7d275bebdc4e.png">

You don't need to dig through the settings to ban a rule that you don't want to see again. The "ban" action of critiques includes entries for global and persisted global banning. <img width="689" alt="screen shot 2017-08-16 at 01 56 08" src="https://user-images.githubusercontent.com/817441/29361519-40a891be-8288-11e7-9db5-10e8869bd0d7.png">

Although there is a global ban, packages can enforce rules. For example, the Kernel package may force the "uncommented class" and "unclassified method" rules, so even if a developer banned the rules globally, they will still see critiques for these rules when working with the Kernel package. <img width="852" alt="screen shot 2017-08-16 at 13 10 42" src="https://user-images.githubusercontent.com/817441/29361615-b42f1c34-8288-11e7-81eb-efbbc7dfd1f7.png">

Renraku is not responsible for the rules that run on top of it. In fact, rules may come from various sources and this is a very powerful feature. On the other hand, Renraku has to assure that its users won't be flooded with exceptions if one of the rules has a bug. Previously Renraku was ignoring all the exceptions by default and had a setting to pass all the exceptions originating from rules is a developer needs that.

In the new version of Renraku every exception is going to be reported with other properties. Every Exception Property stores the execution stack and can open a debugger on it if needed. <img width="698" alt="screen shot 2017-08-16 at 13 03 59" src="https://user-images.githubusercontent.com/817441/29362879-f8b68f2c-828d-11e7-8cd0-411597730dd6.png">

In case you need the old behaviors of skipping or passing all the exceptions, these options are available in the preferences. <img width="401" alt="screen shot 2017-08-16 at 13 11 55" src="https://user-images.githubusercontent.com/817441/29362954-4883916c-828e-11e7-9efc-f7d8ab87d072.png">

Many Renraku details rely on system announcements, and installed source code making them tedious to test. But we worked hard to increase test coverage of the project.

In the rules that use pattern code, one can perform an after-match check on the matched node and the dictionary with wildcard node matches. I.e. if you have a `var variable you had to search the dictionary for an RBPatternVariable named: '`var', and now you can just search for `var.

Originally there were rule subclasses dedicated to checking only classes or methods, this was a poor decision and they were deprecated and removed. Also, the *critic* methods were removed in favor of the ones with *critique* signature. The basicCheck methods of the rules present in Renraku were removed, as they were a part of SmallLint-Renraku transition.

Renraku instruments multiple entities such as classes methods and behaviors with similar functionality, which brings a certain level of duplication to the system. In Pharo 7 the situation got even worse because Traits and Behaviors stopped using common functionality from a trait. As the result, we extracted a common functionality into a single delegate.

Some people found bugs, so we fixed them.