Allow Module Entrypoints in Sub-Files

When using the module entrypoint e.g.:
```
"scriptFile": "../PowerBot/PowerBot.psm1",
"entryPoint": "messageHandler",
```

The function has to be defined in the psm1 file directly, it can't be defined in a sub-file which is the common module development pattern. I assume the parser doesn't actually evaluate the psm1, it just reads that file directly to determine if the functions exist.

## Workarounds
### Stub Function
Define a "stub" function in the .psm1, and replace it later when it actually gets loaded.
```powershell
function messages ($Request, $TriggerMetadata) {}

#Dot source my function which will overwrite the stub at runtime. This works fine
. ./Public/messages.ps1
```

This is kind of an antipattern because you have to keep the parameters in sync between the stub and the actual function.

### "Compiled" .psm1
Use a build script to compile a separated function into a .psm1. This is not desirable because you can't test against source using the azure functions core tools, you have to to build it every time.

## Alternative Implementations
Allow a host.json setting to override the "function exists" check, since it's not material to the actual config (the config is defined in the function.json). This is not desirable because the safety checks are nice, but easier to implement.

Start by reproducing the module entrypoint case with scriptFile pointing to ../PowerBot/PowerBot.psm1 and messageHandler defined in a sub-file. Read the referenced .psm1, function.json, and host.json configuration and trace how the worker checks whether the entrypoint exists. Done means a function defined in a module sub-file is accepted without breaking the existing safety check.

Written by the indexing model from the issue text.