Fix RenderTexture internal sprite positioning and test cases

[rh101]

Describe your changes

This fixes the issue described in #2300 that only applied to CrossFade transitions, along with the RenderTexture tests that would be affected by the new changes to RenderTexture.

A few things to note about the functionality in RenderTexture:

1. The internal sprite is not a child of the RenderTexture
2. The internal sprite is still rendered in the RenderTexture::visit() method
3. The internal sprite must still be activated/deactivated via Sprite::onEnter()/Sprite::onExit() to ensure actions can be run on it
4. The RenderTexture content size is set to the true size of the RenderTexture. This change was made in Set RenderTexture content size on creation #2120 to fix another issue. Due to this, the internal sprite is now positioned in the center of the RenderTexture to ensure it renders into the correct position, which fixes the CrossFade transition position issue.

The default RenderTexture anchor point is 0,0, which is the same default as Node. Since the internal sprite is now positioned in the middle of the RenderTexture, and to keep the old behavior, then the RenderTexture instance must have the anchor point set to the center of the parent to ensure the sprite position it correctly on-screen. So, for example, to render the RenderTexture in the center of the screen, previous usage would have been as follows:

renderTexture->setPosition(Vec2(parentWidth / 2, parentHeight / 2));

Now, since the internal sprite has been moved to the center of the render texture, this is how it should be done, which now also matches how other node types are displayed (such as Sprite etc.):

renderTexture->setAnchorPoint(Vec2::ANCHOR_MIDDLE);
renderTexture->setPosition(Vec2(parentWidth / 2, parentHeight / 2));

Issue ticket number and link

Checklist before requesting a review

For each PR

• Add Copyright if it missed:
  - "Copyright (c) 2019-present Axmol Engine contributors (see AUTHORS.md)."

• I have performed a self-review of my code.

  Optional:

  • I have checked readme and add important infos to this PR.
  • I have added/adapted some tests too.

For core/new feature PR

• I have checked readme and add important infos to this PR.
• I have added thorough tests.

[rh101]

@halx99 The RenderTexture::setSprite() method being public makes no sense to me, since it's only ever used to set the internal sprite that will be used to render the texture belonging to the RenderTexture.

If it is called from outside the RenderTexture class, there is no guarantee it would be valid (could be nullptr), or that it actually points to the internal RenderTexture texture. If it is set to nullptr, then it would cause a crash, since places where the sprite is accessed do not check for a null value.

So, my question is, should this be moved to protected instead of public, or is there a use-case that would require it to be publicly accessible?

[halx99]

@halx99 The RenderTexture::setSprite() method being public makes no sense to me, since it's only ever used to set the internal sprite that will be used to render the texture belonging to the RenderTexture.

If it is called from outside the RenderTexture class, there is no guarantee it would be valid (could be nullptr), or that it actually points to the internal RenderTexture texture. If it is set to nullptr, then it would cause a crash, since places where the sprite is accessed do not check for a null value.

So, my question is, should this be moved to protected instead of public, or is there a use-case that would require it to be publicly accessible?

I think can be protect

[rh101]

I think can be protect

OK! Great, I'll make the change, and if anyone has issues with it then we can revert it back to public access.