Refactor libp2p port's supervision tree

[MegaRedHand]

From https://github.com/lambdaclass/lambda_ethereum_consensus/pull/324#discussion_r1371536270:

I still find this interaction weird and not very elixir-like. Initializing a different module from here and not from a supervisor, or the other's module init is something that seems race-condition-like.

About P2P.IncomingRequestHandler's init: https://github.com/lambdaclass/lambda_ethereum_consensus/blob/33012b8ca3839945dbdf8d0b72fd4440780e022a/lib/lambda_ethereum_consensus/p2p/incoming_request_handler.ex#L16-L30

We should refactor the consumer processes so any failure from the port or the processes is handled correctly.

Also https://github.com/lambdaclass/lambda_ethereum_consensus/pull/324#discussion_r1371542943