Rename CoreGraphics and CoreAnimation

[NikolayJuly]

I see that this package has CoreAnimation and CoreGraphics. And this can actually create name collision. Swift require all targets to have uniq names(which make sense, because every target generate module and they all exists in the same folder)

I'm trying to create some cross-platform app and I created my own CoreGraphics module with some minor implementations which allow me to avoid a lot of #if canImport checks and allow simplify some common code usage. Now I can't depend on this package, because I have name collision. I honestly think I'm not only one who will do the same - implement some types from system framework and name it in the same way to avoid #if checks.

Sine this target are not even product, and looks like just internal target, it would nice, if they were renamed into CoreGraphicsWin32 and CoreAnimationWin32.

If you are fine with idea, I'm ready to do renaming for you and open PR. Wdyt?

[compnerd]

The problem is that some of the types really are expected to be named that way. I'm not sure if I'm fully in favour of renaming them away to something else. I think that part of the fear is that the types that we are defining there are going to require more to be implemented and flesh that out. I think that perhaps one thing to consider is internalising the module so that it is not externally visible, but again, I'm not sure if that is possible as some of the interfaces are exposed.

[NikolayJuly]

My concern still lstands, tbh. But I will close issue.