Switch some unnecessary classes to interfaces

Some of the classes that the Durable SDK exports are essentially serving as interfaces. Here's an example of the `HttpManagementPayload` class:

```TS
export class HttpManagementPayload {
/** @hidden */
[key: string]: string;

/** @hidden */
constructor(
/** The ID of the orchestration instance. */
public readonly id: string,
/** The HTTP GET status query endpoint URL. */
public readonly statusQueryGetUri: string,
/** The HTTP POST external event sending endpoint URL. */
public readonly sendEventPostUri: string,
/** The HTTP POST instance termination endpoint. */
public readonly terminatePostUri: string,
/** The HTTP POST instance rewind endpoint. */
public readonly rewindPostUri: string,
/** The HTTP DELETE purge endpoint. */
public readonly purgeHistoryDeleteUri: string
) {}
}
```

We should consider switching these types of classes to interfaces. The benefit of this:

* Reduces code duplication on our end from having to author both a `.d.ts` file of the class interface, as well as the class "implementation," which essentially does the same thing
* Semantically, these classes may make more sense as interfaces

However, this is technically a breaking change, since using an `instanceof` operator would no longer work on these classes.

Start by reviewing the exported Durable SDK classes, using the HttpManagementPayload example in the issue as the entry point. Identify which exported classes are intended only as data shapes, then assess the compatibility impact of replacing each with an interface, especially for consumers using instanceof. Done means the candidate types and breaking-change implications are clearly defined.

Written by the indexing model from the issue text.