Generalize a method for providing SOAP and REST headers

[StevenMMortimer]

Currently, functions like sf_create and sf_update have API call header options hard-coded into the function definition. For example, all_or_none being the option that "Allows a call to roll back all changes unless all records are processed successfully."

The problem is that there are many more header options for each of these functions that the user may want to take advantage of. We should create a method similar to glm.control() that allows users to freely specify the options in the main function in this case (glm()) or supply it as a list directly to the control argument inside the glm() function.

[StevenMMortimer]

Steps to do:

1. Add a control-like argument to each of the functions to allow the specification of the options
2. Add a glm.control()-like function to the package that is invoked when arguments are not supplied directly to the control argument.
3. Create method validator function (maybe soap_method_header_validator()?) which checks whether the supplied option is available for the method.
4. Implement the validator inside the functions to check whether the supplied controls apply to the method. For example, the DuplicateRuleHeader can only be used with sf_create, sf_update, and sf_upsert. So if someone uses it with sf_delete, then a warning should be thrown, saying that the option is ignored.

This should be done for REST headers and SOAP headers.

[StevenMMortimer]

Many of the REST headers exist in the SOAP headers as well. It is probably best to create a control-like argument defined as list(...) and have a validator that translates and checks anything that is passed into it based on the api_type if it exists.