Factor logic pertaining to each Group within a release to its own object...

This is a rather ambitious attempt at refactoring code into being slightly more amenable to subclassing group elements. 

I've already got [example cases of Group objects on CPAN](https://metacpan.org/pod/CPAN::Changes::Group::Dependencies::Stats), but have no straight forward way to attach them to `CPAN::Changes` beyond sloshing arrays from one module to the other and foisting that task onto consuming code.

So attached, is my best attempt at factoring it in such a way it should be simple to subclass. 

But it needn't be the "accepted" approach, and I'll be happy with any reasonable competiing implementation as long as:

- I can attach arbitrary objects to CPAN::Changes::Release in a straight forward manner.
- (optional, very much desired, but not essential) I can defer determining the values of `changes` for a given section until the time `->serialize` is invoked.

Additionally, you may have other pull requests you have a higher priority to merge. If you want to pull my request later, some reworking to incorporate those changes will probably be necessary, and I'll be quite glad to perform the re-basing work to incorporate those changes in the later pull request.

---

This is mostly to make sub-classing Groups more straight forward so that
one can attach a custom group subclass whos contents aren't determined
until the serialization method is called.

Presently, this tries very hard to hide the fact the internal
abstraction has changed, and no tests needed to be modified to make this
keep passing.

It is intended that legacy code doing complicated things with direct
hash manipulation *should* still mostly work, and automatic upgrades
will be performed as soon as CPAN::Changes gets involved directly.

But it also has scope for breaking things still, as I've not yet tested
this code vs CPAN, nor have I tested it vs DarkPAN.