add psm1 support

[TylerLeonhardt]

I'm going to defer any fancy entry point checking for #15

This allows a user to use a psm1 - they just need to make sure they specify an entrypoint and export that module member.

fixes #46

[TylerLeonhardt]

Question for the room... should I ALSO add psd1 so that a user can use a module manifest?

[daxian-dbw]

It feels to me not useful to allow .psd1, and it would add complexity to how we load a module when LoadFunctionRequest comes in -- there will be request for each files with the legit extension, and we need to know which psm1 is associated with which psd1, this will be harder if the psm1 file has a name that is different from the psd1.

[TylerLeonhardt]

@daxian-dbw I think I'm confused by what you're saying. Why do we need to make the association between psm1 and psd1? If we allow psd1, then a user could have a module manifest that we import and then we try to invoke the entry point they specified.

This gives them the ability to expose that entry point using RootModule, ScriptsToProcess, all of the module manifest goodness.

[SteveL-MSFT]

I don't understand how the .psm1 will get used with AzF. Does this simply mean treating a .psm1 as a .ps1?

[daxian-dbw]

Given our discussion with @joeyaiello, shall we defer the support to .psm1 files?

[daxian-dbw]

@SteveL-MSFT Users are allowed to specify the entrypoint in function.json, so in theory, they can have a psm1 file along with an entry point specified, which is the name of a function in the psm1 file. Then the language worker imports the module and calls that function.

[TylerLeonhardt]

Yeah we can defer this for now, but Dongbo gave good context as to what this is all about.

[SteveL-MSFT]

@daxian-dbw I can see how it's possible, but I don't see the value as it adds complexity for the user

[daxian-dbw]

@SteveL-MSFT We got the same feedback from @joeyaiello when talking to him about this, and decided to put off this change until it's asked by the user.