Refactor FragmentProtocols to remove HasFragments

[AnthonyMDev]

And other cleanup

[designatednerd]

Why is HasFragments no longer needed? Is it worth updating the RFC, which IIRC mentions this?

[calvincestari]

Nicely done!

[calvincestari]

I was wondering how this was working but then realized that this is the 1.0 branch where main works fine without the , because there is no next package. This highlights the importance of making sure the package manager samples work with this branch prior to an alpha release.

[calvincestari]

Thanks for cleaning up the CLI files. For anyone interested they were not deleted from the file system in my PR #2003 and mistakenly only removed from the project.

[AnthonyMDev]

Why is HasFragments no longer needed? Is it worth updating the RFC, which IIRC mentions this?

@designatednerd, It was always an ugly solution and i figured out a better way of doing this. Rather than a HasFragments protocol, the SelectionSet now has an associated type for Fragments itself with a default type of a stubbed type called NoFragments, now you don't need to make them conform to HasFragments, if we generate a Fragments type into a SelectionSet, then you can access the fragments, if not, then the fragments property won't exist (because fragments is a property on a protocol extension on SelectionSet where Fragments: FragmentContainer).

[AnthonyMDev]

As for the RFC, I plan on updating it at some point soon, I've been making a few changes and things are still in flux a little bit, so I'll make a batch update to it around the time we release Alpha 1