[Requestor enchancement] Make the ExeUnit more dockerlike by not expecting the command running on a provider to finish

[cryptobench]

Right now if I want to spawn a long-running service on a provider I most likely need to add & or nohup or some combination of both to run the service on a provider. This is because if you run a command that are not expected to finish like spawning a daemon, then the requestor script times out because it expected to finish it within the x specific timeout time configured in the requestor script.

Sure this might have been a good way for the ExeUnit to work back when Golem was mainly useful for batch-processing tasks, but now that we're stepping into the dApps territory with services, then we should change this.

Why?

1. For Golem to be as easy to use as possible, we should strive to unify the developer experience to the same as working with Docker. We already have a ton of users who know that Golem uses Docker images to compute tasks inside, but it's often missed that while it's Docker Images, it's not actually the exact same thing. So there they already have to learn a new thing to onboard the network as a requestor, but the next thing they also have to learn is that they cannot specify the same CMD or ENTRYPOINT they have in their Docker image, because Golem doesn't support this AND if you know that, then you must instead modify the command that's being ran to something that ends with & . This is just a series of walls for the requestor to bang their head against and I think we should at all cost eliminate this if we want to onboard requestors to the network.

2. If we could expect that converting a Docker Image to a Golem Image would always behave the same way, then imagine how easy it would be to
   2.1) Allow a requestor to onboard the Golem Network
   2.2) Allow anyone to spin up a cloud that uses Golem as its backend for provisioning services that customers request.