Add 'programming model type' configuration setting to 'function.json'

[shreyabatra4]

What problem would the feature you're requesting solve? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

The Python Functions team is in the process of bringing the new programming model to public preview, and it will require support with the Azure portal. We had a chat with Portal folks to enable support for showing PyStein code on the portal, and one of the things that came out from the discussion was to differentiate legacy vs PyStein code patterns (and directory structures).

Describe the solution you'd like

A clear and concise description of what you want to happen.

The requirement is to make it easier to identify new vs old apps by using a configuration setting. Our hope is when _handle_functions_metadata_request, and it is returned successfully, the host adds it to the functions config that is sent back to GetFunctions rest call. This change will help the portal to switch the showing mechanism to other different languages as well, which won't have a function.json to get to, and this the vfs​ calls would fail as well.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

We have been brainstorming and collaborating with the Portal team on other solutions, and felt this solution may be a straightforward way to go, and potentially reusable for other scenarios.

Additional context

Add any other context or screenshots about the feature request here.

[brettsam]

@gavin-aguiar / @fabiocav / @brettsam have some context here

[brettsam]

Recalling the conversation that @fabiocav / @gavin-aguiar / @shreyabatra4 and I had a couple weeks ago. There are two phases to this:

1. [@gavin-aguiar]: Introduce a couple new properties to the function metadata returned by workers, which I believe is here: https://github.com/Azure/azure-functions-language-worker-protobuf/pull/69.
2. [@kashimiz]: Expose these properties to the portal by ensuring they show up during calls to this controller API: https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script.WebHost/Controllers/FunctionsController.cs#L52. This will mainly involve exposing the new properties on the underlying types from the grpc call through to the controller API.

[fabiocav]

This has a dependency on https://github.com/Azure/azure-functions-language-worker-protobuf/pull/69 and we won't be able to complete the changes here until that work is merged.

[fabiocav]

This issue is unblocked now that @gavin-aguiar's PR has been merged. Moving to sprint 124 to track the completion of the remaining work.

[fabiocav]

@soninaren had to work on changes that will ensure the properties are populated as expected, but validation and tests will still be required for this issue.