Support opt-in "merged" transaction scheduling

[tinker-michaelj]

A scheduled transaction is identified by three things:

1. Its memo.
2. Its adminKey.
3. Its scheduledTransactionBody.

If two ScheduleCreate transactions C1 and C2 agree in these fields, we can say they are scheduling the "same" transaction. (Although it is important to note that the payerAccountIDs could differ between C1 and C2.)

---

✖️ Current network behavior

Suppose transaction X requires signatures from both Alice and Bob; and both of them want to schedule X.

So Alice submits C1 with their key and gets SUCCESS. Now Bob submits C2 with their key; but instead of Bob's ScheduleCreate being interpreted as a ScheduleSign that "merges" with C1, the network resolves to IDENTICAL_SCHEDULE_ALREADY_CREATED.

Because it is always possible that Alice and Bob could be accidentally scheduling two related-but-not-truly-identical transactions, this behavior is a reasonable---albeit conservative---default.

---

✅ Proposed change to network behavior

Add a merge_with_identical_schedule field to the ScheduleCreateTransactionBody,

...
  /** 
   * Controls how the network will behave when there is an identical transaction already scheduled (but not yet executed).
   * 
   * If true, this ScheduleCreate will resolve to SUCCESS, and the existing schedule entity will receives any signatures from this transaction.
   * 
   * If false, this ScheduleCreate will resolve to IDENTICAL_SCHEDULE_ALREADY_CREATED, and the receipt will contain the id of the existing schedule entity.
   */
  bool merge_with_identical_schedule = 5;

In the above scenario, if Bob's C2 transaction had merge_with_identical_schedule=true, simply merge its signatures with the existing scheduled transaction created by C1.

⚠️ Make one exception. Namely, if both C1 and C2 gave payerAccountIDs, and they were not the same account, then still fail when handling C2, and resolve to IDENTICAL_SCHEDULE_ALREADY_EXISTS_WITH_DIFFERENT_PAYER.