[feat] Add ability to construct Options object from dictionary

[nwithan8]

Description

The Options object has always been in a weird middle-ground since we introduced parameter objects over a year ago, mainly because it it one of the few object classes in the library that is used in both requests (parameter sets) and responses (property of a Shipment model). Because the object is so large, with several dozen different "properties" (options), we've chosen not to duplicate it into request-specific and response-specific classes, but simply use the existing Options class, designed primarily for response JSON serialization, also for request JSON deserialization in parameter sets.

That has made the Options class difficult to transition to the parameter set construction paradigm we've established, especially because of how many properties it has that can be set.

This PR offers a "shortcut" to allow end-users to use a dictionary (for those still using the legacy dictionary method instead of parameter sets) to generate an Options object via a behind-the-scenes deserialization-serialization process. As with all our legacy dictionary-based functionality, this method relies on the end-user to properly construct a dictionary with the valid schema and key-value pairs (any invalid key-value pairs are inherently ignored and therefore won't produce the anticipated Options object upon de/serialization).

This is potentially the start of a larger effort to offer FromDictionary methods for all the Parameter classes to better facility (and validate) those still using the legacy dictionary workflow. For now, the Options object, due to its double-duty usage and its size and complexity, is the perfect initial candidate for this concept.

Testing

• Added unit test to confirm new FromDictionary method works as expected

Pull Request Type

Please select the option(s) that are relevant to this PR.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Improvement (fixing a typo, updating readme, renaming a variable name, etc)

[HottieHotton]

Adding this will definitely help customers and Support who utilize the .NET library as this will allow flexibility for building scripts to help:

1. Test customer shipments to see what the issue is on their requests
2. Users who have integrated our API via this library condense their code so it can flexible for many options that we support here at EasyPost