Refactor transport logic to be reusable among components

[Und3rf10w]

Basically on the Implant side, the goal is:

• Have each LP the implant is communicating with (this might even enable us to support multiple transports even), maintain their own internal object (a transport.RegisteredServer struct), then do a goroutine for the main interaction logic within that.
• Have a looping (or callable via a command) goroutine to register and/or switch to a new LP

On the LP side, the goal is:

• Have each implant the LP is communicating with (again, might let us support multiple transports), maintain their own internal object (a transport.RegisteredClient struct), then do a goroutine for the main interaction logic that can be initiated for each registered implant (RegisteredClient).
• Have the Teamserver the LP is communicating with (MIGHT let us support multiple teamservers... maybe, maybe not...), be registered in their own internal object (transport.ToBeDetermined, likely transport.RegisteredServer), then do a goroutine for the main interaction logic that can be facilitate interaction between a teamserver and implant.
  • An advantage of having the teamserver be a transport.RegisteredServer in the LP, is that we might be able to further reduce the branching code of a the LP and Team server, and enable them to use the same transport packages. Then we could add transport.RegisteredClient to the implant which would allow the implant to eventually act as a switching relay between implants, facilitating internal pivoting.
• Create a goroutine to add a new implant that can be registered with the LP via the teamserver
  • The idea here is that to register with an LP, and ultimately the teamserver, the new implant's public key and init_signature needs to be known by the LP. By having a feature where a teamserver can essentially whitelist a new implant registration, this will enable us to securely perform new implant registrations, process spawning, etc, and significantly increase the potential lifespan of a Shlyuz operation.

[Und3rf10w]

See #1 for in-progress Merge Request

[Und3rf10w]

Fixed by #1 in d93216b