Refactor how we determine which extensions support deferred binding

[liliankasem]

Today we have have a single SupportsDeferredBinding attribute that extensions can set to indicate that ParameterBindingData can be used (i.e. the extension supports sdk-type bindings). This is used by the FunctionMetadataGenerator to set the "supportsDeferringBinding" property for every function.

The goal for this issue is to refactor the SupportsDeferredBinding attribute so that instead of being a blanket "all or nothing" approach for extensions, we can set the supportsDeferredBinding flag per binding instead. For example, the CosmosDBTrigger does not support deferred binding but we can use deferred binding for the input binding.

• Remove the SupportsDeferredBinding property from the ExtensionInformationAttribute
• Implement an attribute that binding attributes can use to set SupportsDeferredBinding to true or false
• Update the FunctionMetadataGenerator to remove the code that gets the supportsDeferredBinding flag from ExtensionInformationAttribute, and to get that information from the CustomAttribute instead