feat(types): Add TransactionNameChange interface

[AbhiPrasad]

Part of #5679

This PR adds types for the TransactionNameChange interface:

export interface TransactionInfo {
    source: TransactionSource;
    changes: TransactionNameChange[];
    propagations: number;
};

/**
 * Object representing metadata about when a transaction name was changed.
 */
export interface TransactionNameChange {
  /**
   * Unix timestamp when the name was changed. Same type as the start and
   * end timestamps of a transaction and span.
   */
  timestamp: number;

  /** New source applied for transaction name change */
  source: TransactionSource;

  /** Number of propagations since start of transaction */
  propagations: number;
}

TransactionNameChange is an object that describes a point in time when a transaction name was changed. It contains a Unix timestamp (matching with span/transaction start/end timestamps), the transaction source for the changed name, and the number of propagations (when dynamic sampling context was sent to another SDK - through meta tag/http header) that happened since that transaction name change.

Next steps are described in #5679.

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified)	19.46 KB (-0.01% 🔽)
@sentry/browser - ES5 CDN Bundle (minified)	60.11 KB (0%)
@sentry/browser - ES6 CDN Bundle (gzipped + minified)	18.04 KB (0%)
@sentry/browser - ES6 CDN Bundle (minified)	53.03 KB (0%)
@sentry/browser - Webpack (gzipped + minified)	19.83 KB (0%)
@sentry/browser - Webpack (minified)	64.42 KB (0%)
@sentry/react - Webpack (gzipped + minified)	19.85 KB (0%)
@sentry/nextjs Client - Webpack (gzipped + minified)	44.86 KB (+0.06% 🔺)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified)	25.99 KB (+0.1% 🔺)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified)	24.38 KB (+0.11% 🔺)

[lforst]

Just a train of thought: We could explore having two type definitions for all top level options. One that is user-facing, and one that is internal to us. That way we don't create technical breaking changes when we remove values like these again after testing.

Doesn't need action on your part. Just wanted to write that down.

[AbhiPrasad]

I think this is a great point - but it introduces some complexity where we'll need to cast appropriately when working between user-defined and internally defined types, which could cause a lot of trouble (esp in places like tests, or across package boundaries).