Be more explicit about expectations of properties generated FunctionMetadata in FunctionMetadataProvider

Right now, we have different expectations on what `FunctionMetadata` values will/should be used or present based off of the worker time (right now, rpc vs. http).

When the logic is combined in the [same provider](https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script/Host/FunctionMetadataProvider.cs), we sometimes see places where the expectations are blurred.

As an example, rpc language workers need a "language" and "scriptFile" to be present, but http worker's don't. [Here](https://github.com/Azure/azure-functions-host/blob/a2a11fb1adc87d6068019b7c8b6a288c37274201/src/WebJobs.Script/Host/FunctionMetadataProvider.cs#L168), we a non-existent "scriptFile" is logically a proxy for being http worker.

A bug I could see happening: a user creates an http worker that has their `HttpTrigger` folder that includes both `function.json` and `sample.dat`, as most of the templates do. In this case, our logic to determine [scriptFile](https://github.com/Azure/azure-functions-host/blob/a2a11fb1adc87d6068019b7c8b6a288c37274201/src/WebJobs.Script/Host/FunctionMetadataProvider.cs#L223) _would_ actually find that there's another file in there - sample.dat - and set scriptFile to point to sample.dat. I'm not sure if this manifests in a bug, but I could see it very easily resulting in a bug.

Related discussion: https://github.com/Azure/azure-functions-host/pull/5454#issuecomment-572733487