Investigate live objects for trigger objects and input bindings

Today, the only trigger type or input binding that gets a live object (as opposed to a dead object with a bag of static properties) is the `Http` trigger.

For additional triggers, it may be more useful for live objects to come in via the trigger. E.g. users may want "re-hydrated" live objects via the [blob binding](https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-storage-blob), so that they can take those objects and use them in scenarios with Azure PowerShell.

First step here should be to investigate where we put our rehydration logic (is it in the gRPC layer?). Then, we can decide whether this is actually something that users care about, and prioritize a list of bindings/triggers according to customer input.

We should decide which bindings we want to support for live objects within the Preview milestone.

Start by investigating where rehydration logic lives, particularly whether it is handled in the gRPC layer. Review the blob binding and other trigger/input-binding paths, then gather evidence about customer demand. Done means identifying candidate bindings, prioritizing them, and deciding which live-object support belongs in the Preview milestone.

Written by the indexing model from the issue text.