Refactor Confirm components

[danjm]

Currently the confirm component is split into three. This was only meant to be a temporary measure while we were still developing the new ui send component. The intent was to
(a) simplify some more complicated and less readable code that there at the time, and
(b) get a clear picture of the different needs that the confirm component is meant to fulfill

We now need to refactor this to minimize code duplication, maintenance costs and inconsistent behaviour bugs. My proposed refactor is:

• replace pending-tx/index.js and conf-tx.js with a proper container component (which is the purpose it currently fills)
• create one view component that can accomodate different views and actions based on what is mapped to it in the controller component
• plus the points for refactor the send component: Refactor send component #3725
• full unit tests

Before we do this it is probably a good idea to gather requirements for potential future transaction types the confirm component will have to accomodate (e.g. for different erc20 token methods, or methods from other token standards). While we will not add support for these during this refactor, understanding requirements can help us pave the way for those additions during this refactor.

[danjm]

Follow the outline for directory structure and container and component design that is included in the comment here: #3725

[cjeria]

@danjm I'm on the same page as you. In order to design for future transaction types, understanding requirements and their use cases is key.

I've create a design issue that aims to address how to think about ETH-less transaction types (pure function calls) very generically MetaMask/Design#16

This above issue stems from feedback @danfinlay provided in a newly proposed Eth Transfer confirm screen design in this issue MetaMask/Design#11