Add support for SDK types

[castrodd]

This PR adds deferred binding support for blob triggers. This allows customers to use the CollectionInfo object to create SDK clients (note: connection strings will still need to be resolved by customers).

For example:

import { app, InvocationContext, ConnectionInfo } from "@azure/functions";
import { BlobServiceClient } from "@azure/storage-blob";

export async function storageBlobTrigger(info: ConnectionInfo, context: InvocationContext): Promise<void> {
    context.log(`Storage blob function processed ${context.triggerMetadata.name}`);

    const connection = info.content.Connection;
    const connectionString = process.env[connection];
    const containerName = info.content.ContainerName;
    const blobName = info.content.BlobName;

    const blobServiceClient = await BlobServiceClient.fromConnectionString(connectionString);
    const containerClient = await blobServiceClient.getContainerClient(containerName);
    const blobClient = await containerClient.getBlobClient(blobName);
    blobClient.downloadToFile("result.txt");
}

app.storageBlob("blobTriggerExample", {
    path: "example/{name}",
    connection: "myStorage",
    handler: storageBlobTrigger
});

[ejizba]

We typically convert .NET casing to more standard Node.js camel casing (for example https://github.com/Azure/azure-functions-nodejs-library/blob/v4.x/src/converters/toCamelCase.ts)

[ejizba]

I would expect this to be in types/storage.d.ts and have more storage/blob-specific naming

[ejizba]

I don't think we want to expose ModelBindingData/ConnectionInfo outside this package necessarily. These seem more like internal properties that we should handle, not the user. Even in your example, the user's code is only using info.content instead of any properties directly on info.

For example, we might want to check info.version internally and throw an error if the major version doesn't match what we expect. I believe that version property is a schema version for the content property, so If the major version is different the ConnectionInfoContent type we're providing to the user probably won't be right and an error would be appropriate IMO

[ejizba]

We should provide a convenient way for users to turn this off and on instead of hard-coding a value like this. For example in my http stream work, I added an app.setup method where they can enable it. Yours might look different though because I think sdk type bindings can be turned on/off for each individual function whereas for http streams I had to do all-or-nothing for the whole app

[ejizba]

Make sure you sync these changes to the worker repo's core types, which is the source of truth: https://github.com/Azure/azure-functions-nodejs-worker/blob/v3.x/types-core/index.d.ts

Also, not sure if you were aware, but most of the "Rpc" types are auto-generated in the worker repo based on the protobuf api contract. When you run npm run build in the worker repo the rpc types are output to dist/azure-functions-language-worker-protobuf/src/rpc.d.ts. For the core api, we copy the minimal types we need and clean it up a tiny bit (remove unnecessary comments, usually rename it from IModelBindingData to RpcModelBindingData, etc.)