Create a decorator programming model package

Creating a rollup issue to start collecting all the feedback we've been getting on decorators (there's a lot, and it's often conflicting). The idea is we can create a separate npm package (`@azure/functions-decorators`?) that lets you register functions using decorators.

As a bit of background, Node.js has a stage 3 proposal for decorators [here](https://github.com/tc39/proposal-decorators). TypeScript has older support for [decorators](https://www.typescriptlang.org/docs/handbook/decorators.html), which is still labeled experimental but has received a decent amount of adoption already. As the Node.js proposal puts it:
> Unfortunately, we're in the classic trap of, "The old thing is deprecated, and the new thing is not ready yet!" For now, best to keep using the old thing.

We pretty quickly decided we would not be able to use decorators for the [first iteration](https://github.com/Azure/azure-functions-nodejs-worker/issues/480) of the new programming model package because of the above complicated state. However, we could still explore a preview package with decorator support.

Here is a summary of some of the conflicting feedback we've received:

### For
- Feedback from @sinedied [here](https://github.com/Azure/azure-functions-nodejs-worker/issues/480#issuecomment-1062697601)
> I would suggest thinking of how the new API model could leverage TS to make it a first class citizen. For example, I would push forward TS decorators as a way to define bindings and other functions settings. I know decorators' TC39 proposal is currently only stage 2, and TS decorators are already diverging a bit from that proposal. But as syntactic sugar, they're unmatched and AFAIK all most popular TS-first frameworks tools use decorators: Angular, NestJS, TypeORM, TypeGraphQL, Loopback, Ts.ED...

> the fact is that decorators are hugely popular in all TS-first Node.js libs. This is what I think is the most important point here.

### Against

- Feedback from @ChuckJonas [here](https://github.com/Azure/azure-functions-nodejs-worker/issues/480#issuecomment-1236224667)
> IMO, decorators don't bring much other than just making the code read closer what whats done in `C#`. It feels like the `ts` community has shifted away from OOO in favor of more functional code ([decorators are only supported on classes](https://www.typescriptlang.org/docs/handbook/decorators.html#decorators)). Current approach seems more flexible and composable.

- Even some .NET people don't want decorators - see [here](https://github.com/Azure/azure-functions-host/issues/4234)

> I came to this need because I find myself defining many functions very similar to each other, having the same binding types but requiring different values in the bindings, e.g.
> ...
> So, instead of copying the functions over and over again, I'd love to automate this process.