Add StProtocolNameChooserPresenter

[jecisc]

This change introduces a class StProtocolNameChooserPresenter.

This new interface in Spec allows one to select a protocol name to replace the UI in morphic. Features:

• A field to type the protocol name
• A list to suggest the existing protocols in the image and filtered by the pattern written in the input field
• The list sort the items by occurrences in the image so that we suggest the most used protocols first in order to push toward a uniformity of protocols (This was not the case in the morphic version!)
• The input field has the focus to improve user experience and pressing enter will trigger the Ok action (this should not be ncecessary in dialog as they should do it automatically, but that does not work currently so I added it explicitly)
• A class can optionally be given to improve the suggestion. For now it only use it to propose either instance or class side protocols but we can imagine to improve the suggestion checking the protocols of the super classes also or to remove the protocols already present in the class.
• A method to automatically open the dialog and return the protocol name has been added and a block can help configure the presenter and dialog. In case the protocol name is not valid (starts by a * or is empty), a CmdCommandAborted will be raised)

I also propose to merge NewTools-Fuel, NewTools-Compression-Utils and this new presenter in a package NewTools-Utils to avoid having a lot of packages with only one class or one extension method

[jecisc]

I also added a bunch of tests

[jecisc]

Failing tests are unrelated

[Ducasse]

But why merging with fuel? I do not get the idea.

[jecisc]

It's to avoid to have a lot of packages with 1 class or 2 extension methods.

We had Compression-Utils with 2 extension methods and NewTools-Fuel with 2 extensions and 1 class. And here with the protocol chooser it would be yet another package with 1 class

[Ducasse]

Ok but to me the protocol chooser should be packaged with core functionality and zip and fuel not. If we start to group random things then we will get packages with strange dependencies. To me it is not awkward to have tiny packages. So I would package the chooser in a core package and not have a package for it.

[jecisc]

I moved it