Transaction Perspective + View support for equivalent values

[hdevalence]

Is your feature request related to a problem? Please describe.

Recently, we changed the ValueView proto to add support for "equivalent values": #3824

This allows a view server to give out view data that includes numeraire information inside each ValueView, letting us estimate a USD amount of tokens or express a delegation token in terms of the staking token, etc.

However, although this is in the ValueView, we didn't fill in any of the data pipeline needed to actually use it. Prices vary over time, so we want a solution where a price is input in one place and filled out across an entire ValueView. The natural place for this is in the TransactionPerspective.

Describe the solution you'd like

• Extend the TransactionPerspective to allow specifying prices. Off the top of my head, I'd suggest something like

  message TransactionPerspective {
      message Price {
          AssetId priced_asset = 1;
          AssetId numeraire = 2;
          // Multiply units of the priced asset by this value to get the value in the numeraire.
          double numeraire_per_unit = 3;
      }
      repeated Price prices = ...;

  Motivation: we're rendering values, not trying to compute exact prices, so a double is actually appropriate here and much easier to work with for callers. We distinguish the priced_asset from the numeraire for clarity and so that the price is "directional": we want to show GM in terms of USDC but not the other way around.
• Change the transaction view generation code so that every time we construct a ValueView (by augmenting an AssetId with the appropriate Metadata from the perspective), we also use the perspective's prices list to fill in equivalent values: build a map of priced_asset => (numeraire, numeraire_per_unit) and fill in all relevant prices.
• Extend the TransactionPerspective to allow specifying extended_metadata using an Any type
• Change the transaction view generation code to fill in the extended_metadata.

[hdevalence]

Context on extended_metadata and why it's useful: it allows use cases like

• adding ValidatorInfo into a delegation token
• adding position reserves into an LPNFT

In particular, this will allow the web extension to implement the staking page, which has to work with lots of different varieties of tokens.