Multiple improvements

[ArjunVachhani]

@ajinasokan This PR introduces support for async/await and removes the use of dynamic. It also includes several additional improvements:

1. Added async/await support
2. Leveraging System.Text.Json for JSON deserialization
3. Added cancellation support
4. Eliminated the use of dynamic
5. Replaced structs with classes
6. Simplified types (e.g., String → string, UInt32 → int32)
7. Fixing naming conventions so method arguments use camelCase
8. Planned - Introduction of enums
9. Planned - Remove BO(Bracket Order)

[ArjunVachhani]

@ajinasokan Below API are not documented on https://kite.trade/docs/connect/v3/ but exposed in library, should we remove it.

1. Place MF order "/mf/orders"
2. Cancel MF order "/mf/orders/{order_id}"
3. Place MF SIP "/mf/sips"
4. Cancel MF SIP "/mf/sips/{sip_id}"
5. Modify MF SIP "/mf/sips/{sip_id}"
6. Instrument trigger range "/instruments/trigger_range/{transaction_type}"

Also Alerts API is not present in library.

[ajinasokan]

I'm sorry I can't accept this PR as is.

If you are sending a large PR you should ask the maintainers first if this is something they are ready to accept. Create an issue, describe your plan, see if that aligns with the project's roadmap, then work on it and send a PR. Feel free to use this patch for your own use case. But here are the reasons I can't accept this:

1. There are a lot of breaking changes in this PR. We want to maintain certain level of backward compatibility.
2. Async/await will be a massive breaking change. No plans as of now to implement that. If we do, it will be another layer on top of Kite class to maintain backward compatibility.
3. We are already in the works for a major release. Many changes in the PR are fundamentally incompatible.
4. Cancellation is not useful for anything other than GET request. For all critical requests even if the client cancels the request, if the request is fully sent then it will be executed. For an order placement request, async cancellation doesn't cancel the placed order.
5. Some APIs are maintained for backward compatibility and some APIs are not included in the library because they are meant for apps.

Having said that, I will keep the PR open because it has some parts that can be incorporated to the library. Will let you know once that is merged. From now on please make sure to create an issue first describing your plan before sending a large PR.