Update python language worker to support handling new command line arguments with functions- prefix

[kshyju]

The command-line arguments that the language worker receives from the Functions Host have generic names (such as 'host' and 'port'). This can cause conflicts with other environment variables in certain environments. To address this issue, the Functions Host will now send a new set of arguments prefixed with functions-<argumentname>. This will be in addition to the existing arguments.

With the new planned host change, host code will send command line arguments like below.

-host 127.0.0.1 --port 50821 --workerId e9efd817-47a1-45dc-9e20-e6f975d7a025 --requestId cbef5957-cdb3-4462-9ee7-ac9f91be0a51 --grpcMaxMessageLength 2147483647 --functions-uri http://127.0.0.1:50821 --functions-workerid e9efd817-47a1-45dc-9e20-e6f975d7a025 --functions-requestid cbef5957-cdb3-4462-9ee7-ac9f91be0a51 --functions-grpcmaxmessagelength 2147483647

The new arguments sent are:

1. functions-uri
2. functions-request-id
3. functions-worker-id
4. functions-grpc-max-message-length

Initial sanity testing showed that python worker fails to start when the new arguments are sent. We need to fix the python worker to handle these new arguments.

Expected behavior with the fix:

1. Use the new arguments (the one with "functions-" prefix).
2. If the new arguments are not present, use the old ones (PORT, HOST etc..)

See https://github.com/Azure/azure-functions-host/issues/9504 for more details.

[kshyju]

cc @vrdmr

[kshyju]

~For any language workers which are consumed as a NuGet package to host, we do not necessarily need the fallback code (using the old arguments). This is because the next host version which will consume the language worker package, will be always sending the new arguments.~