Add Registration Missing lots of fields

[Carbon8Jim]

When adding registrations, the current library only permits the passing of First Name, Last Name and Email. It would be great to have an additional variable that we could pass in address, city, state, zip, country, org, industry, phone, job_title, etc. It could be implemented as a model such as RegistrantDetail and just passed as a single object with a default of null, Since my organization makes certain fields required, I am unable to use the function as it currently exists. I am happy to implement this feature and contribute if that would accelerate it's adoption, since my current solution is going to be forking this project and updating it so I can get my app to work until a potential update would be performed

[Jericho]

Yes indeed, several fields are missing. This is discussed in #156 and is being tracked in #157.

I started working on this (See: https://github.com/Jericho/ZoomNet/tree/feature/registrant_fields) but soon hit a road block: my Zoom account is not authorized to add registrants to a meeting or a webinar. So I signed up to be part of Zoom's ISV program which would grant me access to all their API functionality but I still haven't heard whether they accept or reject my application. I also asked for help in #160 : if you know anybody who works at Zoom and could influence the decision to accept my application, please put me in touch.

[Carbon8Jim]

My zoom account s authorized for both webinar and adding registrants. We have extra licenses and I would be happy to give you access to one of our licenses to work on this feature. Just let me know. Or I could just setup an account for you and create a marketplace apt and just send you the api keys for that account.

[Jericho]

That's very generous of you. I will gladly take you up on this offer.

Go to the Nuget page of ZomNet and click on "Contact Owners". This will allow us to continue this discussion via email and share api keys, tokens, etc. without publicly publishing them on GitHub.

[Jericho]

Closing this issue in favor of #157.