Official operations - deposits unit test

[mratsim]

For now:

• deposits block. This required ignoring invalid signatures in deposits (previously we asserted they were valid)

some tests deactivated due to #407 (skipValidation flag too strong so we don't trigger assertion when passed something that the spec expect to fail)

[mratsim]

Deposits CI:

• Linux is passing
• 32-bit windows is passing
• 64-bit is failing (https://ci.appveyor.com/project/nimbus/nim-beacon-chain/builds/27264839/job/5sqvvn917k1744p2#L3035) with:

[Suite] Official - Operations - Deposits  [Preset: minimal]
    Unhandled exception: The parameter is incorrect.
 [OSError]
  [FAILED] [Valid]   new deposit under max (new_deposit_under_max)
    Unhandled exception: The parameter is incorrect.
 [OSError]
  [FAILED] [Valid]   new deposit max (new_deposit_max)
    Unhandled exception: The parameter is incorrect.
 [OSError]
  [FAILED] [Valid]   new deposit over max (new_deposit_over_max)
    Unhandled exception: The parameter is incorrect.
 [OSError]
  [FAILED] [Valid]   invalid signature new deposit (invalid_sig_new_deposit)
    Unhandled exception: The parameter is incorrect.
 [OSError]
  [FAILED] [Valid]   success top-up (success_top_up)
    Unhandled exception: The parameter is incorrect.
 [OSError]
  [FAILED] [Valid]   invalid signature top-up (invalid_sig_top_up)
    Unhandled exception: The parameter is incorrect.
 [OSError]
  [FAILED] [Valid]   invalid withdrawal credentials top-up (invalid_withdrawal_credentials_top_up)

[mratsim]

Note that Appveyor CI without -d:release is crazy slow, x86 (32-bit) has been running for almost 40 min at the moment.

[mratsim]

The CI fails on -d:release on windows 64-bit (and works on 32-bit).

It seems like the error thrown "The parameter is incorrect" seems to be thrown by windows and reraised with raiseOSerror(osLastError())

[tersec]

I'd be happy to merge this with something akin to #438 included either as part of the initial merge or after the fact.

[mratsim]

let's merge it