Bug 8031 – If a class have some signals it's impossible for a derived class to have any signals

`Signal` methods should never ever by virtual. We don't want user to override connect/disconnect etc. All `Signal` methods are virtual. As a result with current named mixin templates behavior (they can add virtual methods): --- import std.signals; class A { mixin Signal created; } class B : A { mixin Signal moved; // Yes, it overrides `created` signal! } --- or even worse: --- import std.signals; class A { mixin Signal s1; mixin Signal s2; } class B : A { mixin Signal s3; // Guess what A signal is overriden? } --- or even worse: --- import std.signals; class A { mixin Signal s1; } class B : A { // Guess what exectly is overriden? // Spoiler: unhook is overriden! mixin Signal!int s2; } --- Hello heisenbugs for every unlucky person who doesn't compile with `-w`! That's why it's impossible to use `std.signals` in any GUI library for now.

Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/05a8f316e7e497bcf3c44a5607a9a87da207a7d6 Fix Issue 8031 - If a class have some signals it's impossible for a derived class to have any signals All `Signal` methods should be `final` because if they aren't it's impossible to add any signals into a derived class. And yes, lets make `Signal` a `mixin template`.

Since https://github.com/D-Programming-Language/phobos/pull/567 has been merged now it's impossible for a derived class to have signals only if a base class has the one and only signal (because of Issue 5028) and this isn't a major luck of functionality.