soroban-simulation refactoring followups

[dmkozh]

This is a list of suggested followups enabled by the soroban-simulation changes (#92). None of these are critical to be implemented, this is just a dump of potential possibilities to consider:

• Return contract_events separately from diagnostic_events. Contract events are hashed into ledger and thus can be used for off-chain applications, while diagnostic events are intended for the contract and dapp developers and are not standardized and might change with time. With the clear distinction it's easier for the users to distinguish between the two, e.g. wallets could use this to tell with confidence which transfers have happened during simulation without the risk of reporting a diagnostic event that imitates a transfer.
• Return simulated_instructions/memory in respectively named fields (with the respective documentation). These will always be populated, even in case of the failure, which could help contract developers to debug their contracts. There is also an option to explicitly return the adjusted instructions as a separate field for the ease of access)
• Return modified_entries in the response (optionally?). These represent the states of all the writeable entries before and after the host invocation. This is important for wallets to be able to present the transaction effects to the user, but also may be a generally useful debugging tool for contract developers.
• Provide configuration mechanism for Soroban RPC to configure the default simulation adjustments without recompilation. The adjustments can then be passed directly to soroban-simulation.
• Expose the simulation adjustments to the users via request parameters
• Pass lists of keys in ExtendTtl/Restore ops instead of operation body XDR - this reduces the risk of providing a bad simulation request as currently the user has to be aware that RO footprint is used for TTL extension and RW footprint is used for restoration