[BUG] ITelemetryItem uses intersection type instead of union type for tags property

[devm33]

The ITelemetryItem interface uses an intersection type (&) between Tags and Tags[] instead of a union type (|). There's a note on the line that Tags[] will be deprecated:

https://github.com/microsoft/ApplicationInsights-JS/blame/f9d5ec1e2045f6206c8d7dc9b0cb3e6509f45473/shared/AppInsightsCore/src/JavaScriptSDK.Interfaces/ITelemetryItem.ts#L37

However using an intersection type forces passing an array in order to satisfy the constraints of Tags & Tags[]:

Type '{ [key: string]: string; }' is not assignable to type 'Tags & Tags[]'.
  Type '{ [key: string]: string; }' is missing the following properties from type 'Tags[]': length, pop, push, concat, and 29 more.

[MSNev]

Just had a quick look at the code and I think we can just remove the Tags[] as Tags is defined (and used -- based on quick look) as an object with dynamic keys -- so the only "real" usage would be if this is set as a tag with a numeric key.

Actually, we have 2 tags objects and the ITelemetryItem one is initialized as an array.

@siyuniu-ms can you have a look and see the impact of removing the Array definition, I suspect that we might need to "grow" some ArrayLike support for the Tags interface without updating all of our tests.

While I initially thought that this would be a good candidate for 3.1.0, I'm not so sure now.

@devm33 Which version of TypeScript is throwing this error?

[MSNev]

Also, because of backward compatibility support, this might be problematic -- so as suggested it might just be easier to change the definition to a union type as suggested (rather than removing the Tags[] definition completely.

[devm33]

@MSNev I'm running 5.1.3. The point I was trying to raise was the current typing is preventing passing Tags. It only accepts an array. Which based on the comment seemed like the opposite of the intention.

[MSNev]

Yeah, it looks like someone in the past tried to convert this to an object (and when we construct the outbound serialized form this is what we do), and while this definition "works" (from a previous version and raw JS perspective), it's problematic -- especially if the latest versions of TS are now enforcing this more.