What

Update the parsing done in stellar contract restore cmd to allow for more LedgerEntryChange patterns.

Why

We previously had a select few patterns that we were matching from the restore tx's changes, to get the updated TTL to return to the user on the CLI. However, we were missing some valid matches i.e.

[Restored(LedgerEntry { 
	last_modified_ledger_seq: 3895, 
	data: Ttl(TtlEntry { 
		key_hash: Hash(83a1270ef2b7bbe3e14e5c4b4538d071ad0a436ab4ef22a5f16a5dda26604b53),
		live_until_ledger_seq: 4694 }), 
	ext: V0 }),

 Restored(LedgerEntry { 
	last_modified_ledger_seq: 247, 
	data: ContractData(ContractDataEntry { 
			ext: V0, 
			contract: Contract(ContractId(Hash(bcb0fd9dfa6eadbf03049c1469716ac103ce5a37e917d9a4efde75b3cae0b5a1))), 
			key: Symbol(ScSymbol(StringM(COUNTER))), 
			durability: Persistent,
			val: U32(1)
		 }), 
	ext: V0 })]

Known limitations

I did a refactor that would allow for any LedgerEntryChange types, as long as the data field is a ttl entry (LedgerEntryData::Ttl), and then take the largest live_until_ledger_seq value of the change set. I would love another set of eyes on this for confirmation that this is ok. Since this is just impacting parsing and displaying the tx's result it should be fairly safe, as it won't effect the tx or restore logic at all.