[Tech Debt]: split TokenIF interface into internal and external interfaces

[emilydrakesmith]

What is needed?

Throughout the app we use an interface called TokenIF to describe the shape of token metadata objects. It currently looks like this:

export interface TokenIF {
    name: string;
    address: string;
    symbol: string;
    decimals: number;
    chainId: number;
    logoURI: string;
    fromList?: string;
    listedBy?: string[];
    walletBalance?: string;
    dexBalance?: string;
}

The required properties are part of the industry standard to shape a token data object. The optional properties are additional metadata for internal use and added by in-app middleware. This architecture is used so that one interface can describe data objects in both the raw form received from outside endpoints (as well as the Ambient token list) and decorated data objects consumed in the app.

This is problematic because some decoration values (chiefly fromList) are ubiquitous in the app and should not be treated as optional. We should adopt a new standard that uses two interfaces. The first interface will conform to the industry standard with no decorations. This will be used to describe the shape of raw external data fetched by the app before being decorated. The second interface will extend the first and describe the shape of decorated data. This achieves single source of truth for both interfaces and will improve developer experience by making it easier to use decorations that are omnipresent in the app.

This architectural change should later be applied to other types of data that the app receives from a server, either our own or third party, and the work to resolve this tech debt will be a model for future refactors.