MSP curve is hardcoded in constructor, ignoring `IdemixMSPConfig.CurveId`

[adecaro]

Summary

NewIdemixMsp and NewIdemixMspAries both hardcode the elliptic curve at construction time —
FP256BN_AMCL for the dlog scheme and BLS12_381_BBS for the Aries scheme. However,
IdemixMSPConfig already carries a curve_id string field (populated by idemixgen --curve)
that is intended to communicate the correct curve to the MSP. Setup never reads this field,
so it is silently ignored.

Impact

• An MSP config generated with idemixgen --curve BLS12_381 will fail to set up correctly
  when loaded through NewIdemixMsp, because the keys are deserialized against FP256BN_AMCL
  instead of the curve they were generated with.
• There is no error when the config Type and the constructor disagree: calling
  NewIdemixMsp (dlog) and then Setup with an IDEMIX_ARIES config silently proceeds
  rather than rejecting the mismatch.
• Users who want to inject a custom logger must subclass or wrap the MSP; there is no
  constructor overload that accepts a Logger.

Expected behaviour

1. Setup should read conf.CurveId and build the BCCSP with the matching curve and
   translator, rather than using a hardcoded value from the constructor.
2. NewIdemixMsp should only accept configs of type IDEMIX; NewIdemixMspAries should
   only accept configs of type IDEMIX_ARIES. A mismatch should be an error.
3. NewIdemixMspAries should restrict curve_id to BBS curves
   (BLS12_381_BBS, BLS12_381_BBS_GURVY) and error on any other value.
4. Callers should be able to supply a custom Logger at construction time without having
   to wrap the MSP.

Default / backward-compatibility

• dlog: empty curve_id → FP256BN_AMCL (preserves current behaviour).
• Aries: empty curve_id → BLS12_381_BBS (preserves current behaviour).