Make OriginateResponse inherit ManagerReponse

[stoyandimov]

All manager responses inherit ManagerResponse except OriginateResponse. Since OriginateResponse is also a manager response, this PR will make it inherit from ManagerResponse. This is to allow generic methods that expect ManagerResponse derived classe to accept OriginateResponse as well.

Addresses #268

[Deantwo]

Does this even compile?
I see private string uniqueId; exist in both and you did not delete it in OriginateResponse.

OriginateResponse now inherit IParseSupport through ManagerResponse, does this cause any issues?

ManagerResponse has a bunch more properties, are they supplied in the AMI's OriginateResponse event?
Doesn't look like it has all of them, see: https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+ManagerEvent_OriginateResponse
It it ok for it to have some of those missing?

Basically just a bunch of possible consequences you haven't mentioned. And I don't have the time to check all of them at the moment.

[stoyandimov]

Does this even compile? I see private string uniqueId; exist in both and you did not delete it in OriginateResponse.

It does compile with a warning about shadowing the public string UniqueId but I should indeed fix that.

OriginateResponse now inherit IParseSupport through ManagerResponse, does this cause any issues?

This will attempt to automatically parse attributes if any.

ManagerResponse has a bunch more properties, are they supplied the AMI's OriginateResponse event? Doesn't look like it has all of them, see: https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+ManagerEvent_OriginateResponse It it ok for it to have some of those missing?

The asterisk reference is more relevant to AsterNET.Manager.Event.OriginateResponseEvent. The ManagerResponse adds properties related to how AsterNET deals with the messaging and not so much attributes that AMI would send. To be honest I'm not 100% sure what is the difference between the two OriginateResponse and the OriginateResponseEvent

Basically just a bunch of possible consequences you haven't mentioned. And I don't have the time to check all of them at the moment.

You are absolutely right. Those side effects should be tested for. I've already merged this into our project but I'm yet to do intensive testing with originating calls.

I'll convert the PR to a draft and will reopen it (or close it) after I do some more tests. I will post updates here.

Meanwhile please, do not close #268. If it turns out things break, I'll post an answer there.

[stoyandimov]

The project using AsterNET has been discontinued so I won't be able to perform the tests mentioned above. I'll mark the PR as ready for review in case someone run against the same issue and would like to test the proposed solution.