Support passing a user-defined state value to AuthCodeURL on public clients

[dcormier]

Related to #485, #227, and #407.

[bgavrilMS]

Why do you need to pass in your own state on public client? MSAL should perform both legs (authorization call and token call) on public client.

I can understand this scenario for confidential client, where you need MSAL only to generate the auth code URL, redirect the user there and then MSAL calls AcquireTokenByAuthCode

[dcormier]

Maybe it isn't needed. I'm using the confidential client and needed it. I started working on it before seeing #485 was sitting there. I had done both sides since the functionality appeared similar, so I figured I might as well submit it.

[rayluo]

Why do you need to pass in your own state on public client? MSAL should perform both legs (authorization call and token call) on public client.

I can understand this scenario for confidential client, where you need MSAL only to generate the auth code URL, redirect the user there and then MSAL calls AcquireTokenByAuthCode

Agreed with what @bgavrilMS said.

Also want to add that some MSALs historically have the generate auth url function even in public client, and it looks like MSAL Go does. So, technically we could have added state support for that legacy function. But perhaps we shouldn't bother, and just deprecate that function and ask app developers to use public client's interactive function instead. If you would also agree, let's close this PR and close issues that are public-client-only as wontfix.

[bgavrilMS]

You can update the auth code URL manually for this.