Consider adding `agent` paremeter to `BTPlayer` to propagate upon `BehaviorTree` initialization

[Wilson E. Alvarez]

Currently BTPlayer hardcodes BTTask.agent to be the scene owner where BTPlayer lives upon a BTPlayer + BehaviorTree initialization. I don't see a reason not to have BTTask.agent be the parent node of BTPlayer by default.

This will be specially useful for new users since they will be able to have multiple BTPlayer nodes within the same scene and be able to assign their desired agent by selecting a node instead of walking the BehaviorTree to set the agent they want.

[Serhii Snitsaruk]

Good points. And it would be nice to have set_agent_recursive() method in BTTask.
The tricky part is the state machine, I think. Classes such as LimboHSM, LimboState and BTState, they also have an agent.

EDIT:
I no longer think that having set_agent_recursive is a good idea (or any form of set_agent). Some tasks could have initialization logic in _setup that depends on an agent instance. Executing such a method after initialization can break custom task logic.

[Serhii Snitsaruk]

There's another tricky part to implementing this proposal. Let's say a user exports a Nodepath variable to use in a custom BT task:

extends BTAction

@export var hitbox_path: NodePath

func _enter() -> void:
    var hitbox: Area2D = agent.get_node_or_null(hitbox_path)

When you select an instance of this task to edit in the inspector, by default, the NodePath property editor will allow you to select a node in the current scene relative to the scene's root node. The root node in this case is the owner of BTPlayer, and that's why it is implemented this way in LimboAI. This also affects BBNode which relies on the agent to be the owner too and for the same reason.

EDIT:
One way of solving it would be passing both agent and owner to each individual task. Although, it is confusing what owner actually means for BTTask.

[Serhii Snitsaruk]

Implemented in #102