Refactor code to start using transaction type to drive UI's handling of transactions

Nobody has claimed this yet.

Different transaction in ethereum can have different formats and the different formats needs to be handled differently, in addition transaction handling also depends on what type of transactions network and account support. Thus in the `UI` code we have end up creating conditional chaining to check all these various conditions for handling transactions.

This can be simplified by using [transaction type](https://eips.ethereum.org/EIPS/eip-2718), every transaction in ethereum has a type, each transaction of a type will require to be handled by `UI` in same way. Type of transaction is either send by user or it can be derived using information about network and account. In fact currently also we derive type of transaction before submitting transaction.

If we use type of transaction to decide how `UI` should handle it that will simplify our code. Currently there are 3 transaction envelope types but will be more in future, and this approach will help to handle the future cases also easily.

The task is going to require refactoring in a couple of components around transaction handling and also some smaller changes in controllers.

Start by tracing the UI transaction-handling components and controllers, then locate where transaction types are currently derived before submission. The refactor is done when UI handling is driven by transaction type rather than repeated conditional checks, while supporting the existing transaction envelope types and leaving room for future types.

Written by the indexing model from the issue text.