Rework Safe Signer Launchpad

This PR does a rework of some of the implementation details of the
`SafeECDSASignerLaunchpad` contract in light of some observations from
the previous PR #376.

Namely, this changes the initialization process to work in a slightly
different way:
1. Set the target singleton to a special slot when the entry point
   executes the `initCode` for the account
2. Signature verification checks that the account is an owner. This has
   the side-effect that you can initialize an account with multiple
   ECDSA owners and use any of them to sign the first user operation.
3. Promote the Safe to the singleton that was previously in storage.

The main difference with the previous flow is that we no longer have two
separate `setup` initializers that we `DELEGATECALL` to. Additionally,
we added checks that prevent double initialization as well as reentrency
issues in the execution function.

In addition, this also opens up a pretty clear path for supporting
multiple owners with the launchpad as the account has already undergone
"regular" Safe setup. This is relevant for #372.