Character movement rework

[wnbaum]

Replaces pong paddles with SimpleCharacter nodes.

Adds a new block for CharacterBody2D that allows for custom key input for movement (without having to think about vectors).

Also changed the SimpleCharacter movement block to not use input actions, but hardcoded keys instead.

Had to do some minor refactoring to get the exported texture property of SimpleCharacter to work in game, since the original script was getting overridden by the block script. Block scripts extend their parent node script, so the superclass _ready method will get called, however, the script variables (such as exported ones) get replaced when the script gets replaced. This is another reason to look into block interpretation. Instead of replacing the script, we could just call the top level block function from the existing parent script.

https://phabricator.endlessm.com/T35515

[manuq]

@wnbaum can we define input actions in a "simple blocks" or "high level blocks" autoload? If so we can keep the input handling as before. I plan to do the same for the scoring.

[wnbaum]

@manuq You could do that if you want! Not sure if you need an autoload, you could just call a function on block_code_plugin's enter_tree and exit_tree to add and remove the actions.

If you want to have a global Add score block or similar, an autoload is a good idea, but if you are adding a SimpleScoring component, then the user could just wire up signal blocks the notify the SimpleScoring block to update the score. Either way is good, I kind of prefer the implement it yourself with a component way since you can decide if you want the scoring HUD or not.

[manuq]

@manuq You could do that if you want! Not sure if you need an autoload, you could just call a function on block_code_plugin's enter_tree and exit_tree to add and remove the actions.

Awesome. In that case, I think this PR would be much better by defining input actions for the Player 1 / Player 2 movement.

Thanks for the advices for the scoring component!

[wnbaum]

Rebased! For now I think its fine to have the input actions hardcoded, since adding them on plugin initialize requires the project to be restarted, and that doesn't make sense to have to do if you are installing from AssetLib. I like how the example is now a standalone scene too.