Update getMeetingDetailsVerbose Interface

[MSJohnnyLee]

For more information about how to contribute to this repo, visit this page.

Description

This PR modifies the return interface of the getMeetingDetailsVerbose API. Specifically, the response.details.originalCaller and response.details.dialedEntity properties.

originalCaller represents the caller of a call, and dialedEntity represents the callee. Those two properties originally were of type string, and the return value could've been either an email or phone number in string format.

With this change, two additional properties were added to replace them: originalCallerInfo and dialedEntityInfo. Those two properties are of a new type ICallParticipantIdentifiers. This new type ICallParticipantIdentifiers is an object that has 2 explicit fields for phoneNumber and email.

This new type serves two purposes: 1. The returned value is more explicitly defined 2. The response can return both a phone number and email if that information can be retrieved.

In addition, this change also a new optional property, callId.

This PR is a follow up to the original PR that first introduced the getMeetingDetailsVerbose API:
#2206

Main changes in the PR:

1. Create new interface ICallParticipantIdentifiers
2. Deprecate response.details.originalCaller and response.details.dialedEntity
3. Create two new, optional properties response.details.originalCallerInfo and response.details.dialedEntityInfo of the new interface ICallParticipantIdentifiers
4. Create new optional property callId

Validation

Validation performed:

1. Validated in Orange that the new meeting.getMeetingDetailsVerbose API returns the new response.details.originalCaller and response.details.dialedEntity properties in a supported host
2. Ran automated test cases

Unit Tests added:

Updated existing test

End-to-end tests added:

Updated existing test

Additional Requirements

Change file added:

Yes, added change file

Related PRs:

Original getMeetingDetailsVerbose PR: #2206

[TrevorJoelHarris]

If you could put this in its own file (emailAddress.ts) in this folder I would really appreciate it. Same for the unit tests being in their own test file. I'd really like us to start using classes like this in other capabilities as well, so moving this to its own file will make it easier to find and share.

If you do this, remember to add the class to the index.ts file (look for where the appId.ts file is referenced for an example)

[TrevorJoelHarris]

Please split these into separate tests (one test for each invalid case, and then a single test for all of the valid ones together is probably okay) This will make it more obvious what is wrong if something breaks.

[TrevorJoelHarris]

Looks good, just one last request to split EmailAddress and its test into separate files