Introduce unified MethodCallTransactionBuilder & deprecate MethodCallParams.Builder

[jasonpaulos]

This PR fixes a few related issues with MethodCallParams.Builder:

• It uses different setter names from the other transaction builders (e.g. setAppID vs applicationId)
• It lacks some convenience methods for setting fields (e.g. setSuggestedParams only accepted a v1 TransactionParams object, not a v2 TransactionParametersResponse object)
• It contains some minor logical errors, such as:
  • Always setting both suggested parameters and first/last valid rounds and fees
  • Exposing members as public when not necessary

To remedy these, I've followed @winder's suggestion to make a new MethodCallTransactionBuilder class, similar to the other transaction builder classes. To make sure this class uses the same methods as the other builders, I've done the following:

• Make TransactionBuilder and MethodCallTransactionBuilder inherit from a new TransactionParametersBuilder class, which contains all common transaction parameters and their various setters.
• Introduce new interfaces StateSchemaSetter, TEALProgramSetter, and ApplicationCallReferencesSetter. These interfaces define setter methods for various application call transaction fields, and their purpose is to unify these setters between the application call transaction builders and the new MethodCallTransactionBuilder.

And to preserve backwards computability as much as is reasonable, the original MethodCallParams.Builder class still exists as an adapter between the preexisting interface and the new MethodCallTransactionBuilder class, though it is now deprecated.

Backwards incompatible changes are:

• MethodCallParams.Builder's members are no longer public.
• MethodCallParams's members have changed to reflect the internal types of the new MethodCallTransactionBuilder, and have become final. Its constructor has changed accordingly.

Closes #323

[michaeldiamant]

@jasonpaulos Thanks for your effort to supply a fix here! ☕

It's the 1st time I've substantively interacted with java-algorand-sdk, so take my approval with a grain of salt.

• I think the PR definitively addresses the bug and provides a solution for build conformance.
• Noting a passing concern - Generally, I am fearful of inheritance chains because they often increase fragility. I'm not requesting a change, but I feel obligated to vocalize the concern as a reviewer.
  • I don't have enough experience with the repo to gauge the level of concern with TransactionParametersBuilder.
  • The inheritance is an expedient way to provide the same API. From a brief scan, I don't immediately see what other abstract classes may appear.

[michaeldiamant]

@jasonpaulos Approval note missed in previous comment: Since I don't yet have a well-defined view here, I'm trusting the provided level of backwards compatibility is in conformance with repo conventions + norms.

[ahangsu]

thanks for the discussion #324 (comment), and now I understand the reason behind the syntax T extends ...<T> among all the txn builder.