Split unix cmd generic_sh encoder

As pointed in #3518, sometimes the "-e" echo flag doesn't work as expected. Having both perl and echo encoding in the same module makes hard to find a good solution without bypassing the encoding with tricks like using ```payload.raw```.

After discussing the issue with @jlee-r7 and @hmoore-r7 this pull request tries to solve having into account their feedback. Review from them / others would be super appreciated! Maybe there is a better / more elegant of doing it. Or here are issues! I would appreciate any feedback! I would love to allow cmd unix encoders to be flexible enough to deal with situations like #3518 but I don't want to waste actual encoding!

Clarification for some points:

The main idea is to split the perl and echo encoding in two different modules (encoders), ~~giving an higher rank to the perl encoding (because the -e echo option isn't always available).~~ It has been preferred over allowing an ```EncoderOption``` to disable echo in the old ```generic_sh``` encoder.  **EDIT:** favoring echo encoding for back compatibility, modules can force perl encoding with EncoderType still.

~~CMD unix encoders now provide ```RequiredCmd``` compatibility, so the exploits can enable/disable encoders from ```Compat => Encoder => RequiredCmd```~~

~~The cmd unix encoders can set ```RequiredCmd``` to ```*```. In this way an encoder is marked as "always compatible" when the module sets ```Compat => Encoder => RequiredCmd```.~~

The old ```generic_sh``` ~~is provided with ```LowRanking``` still. If a CMD unix exploit needs back compatibility it can be accomplished by adding the next metadata to the module~~ **is deleted**.

~~A module can also set ```EncoderType``` to force the use of the old ```generic_sh```, of course.~~

~~My main worry about back compatibility is which now we're favoring perl encoding over echo encoding. With ```generic_sh``` echo encoding was preferred in some cases.~~

After reviewing carefully a lot of times encoding is not being applied, because lot of UNIX cmd exploit haven't badchars. In this case the old ```generic_sh``` doesn't apply encoding. 

On the other hand, normally perl encoding should be an issue only on restricted environments or embedded devices. 

~~After reviewing the list of modules, I've located just two cases where the old behavior will change and perl could be an issue. I've modified the two modules to allow back compatibility with the patter explained above. If there are concerns about other modules, they can be updated with the pattern above to allow back compatibility.~~

Again, any feedback is super welcome here!