[feat] Add support for the device authentication flow for github apps

[PierreBtz]

Description

Opening as a draft since the tests are not ready and I have questions about them

This PR provides support for the device authentication flow for github apps, as documented in https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-user-access-token-for-a-github-app#using-the-device-flow-to-generate-a-user-access-token (access token generation) and here https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/refreshing-user-access-tokens#refreshing-a-user-access-token-with-a-refresh-token (refresh token).

This is needed when developing java CLIs that need to authenticate to GitHub through a GitHub application.

Reproducing here the documentation to help with the understanding:

  In order to authenticate to GitHub as an user using the device flow of your GitHub App, you need to use the <<<DeviceFlowGithubAppAuthorizationProvider>>>
  authentication provider that will take care of retrieving a user access token and refresh it when needed for you.
  You need to handle two things by yourself:
  1. You need to provide a <<<DeviceFlowGithubAppCredentialListener>>> that will be called when a new user access token is retrieved (either on initial creation or on refresh).
  It is up to you to store the credential object securely the library does not take care of that.
  2. You need to provide a <<<DeviceFlowGithubAppInputManager>>> that will be called when a user interaction is needed to complete the device flow.
  The library provides a basic implementation <<<LoggerDeviceFlowGithubAppInputManager>>> that will log the instructions to the console but you could imagine a more complex
  implementation that would for example open the user browser automatically (or call some automation that will input the information automatically for instance).

  Here is a complete example to get started:

+-----+
        var clientId = "<clientId>";
        var objectMapper = new ObjectMapper();
        objectMapper.registerModule(new JavaTimeModule());

        // for demo purpose only, this is not proper secret management!!!
        var appCredentialsFile = Path.of("/tmp/github-app-credentials.json");
        DeviceFlowGithubAppCredentials appCredentials;
        if (Files.exists(appCredentialsFile)) {
            appCredentials = objectMapper.readValue(appCredentialsFile.toFile(), DeviceFlowGithubAppCredentials.class);
        } else {
            appCredentials = EMPTY_CREDENTIALS;
        }

        var gh = new GitHubBuilder().withAuthorizationProvider(
                new DeviceFlowGithubAppAuthorizationProvider(clientId, appCredentials, ac -> {
                  // in this basic example, we serialize the credentials as json to a file
                  // this is not proper secret management and you should probably use something more secure
                    try {
                        objectMapper.writeValue(appCredentialsFile.toFile(), ac);
                    } catch (IOException e) {
                        throw new RuntimeException(e);
                    }
                }, new LoggerDeviceFlowGithubAppInputManager())).build();
+-----+

Opened questions I have:

• I'm not too happy that the main class (DeviceFlowGithubAppAuthorizationProvider) cannot be in the authorization package (needs access to a package protected method).
• I'm not too sure how to process with tests: I cannot use the recording method since the authorization process is not going through the api endpoints but through the UI ones (https://github.com/...). I didn't find anything in the base class test that would help with this. Also I have to use the .setRawUrlPath("https://github.com/login/oauth/access_token") which cannot be intercepted as is obviously. This is not only a problem for tests but also for on prem Github and my current thinking is that I need to enrich the API and the testing framework to support a uiUrl that would be the equivalent of the apiUrl for the UI.

Since this starts to widen the impact of this change I'm opening this draft to discuss the potential approaches before going further.

Before submitting a PR:

• Changes must not break binary backwards compatibility. If you are unclear on how to make the change you think is needed while maintaining backward compatibility, CONTRIBUTING.md for details.
• Add JavaDocs and other comments explaining the behavior.
• When adding or updating methods that fetch entities, add @link JavaDoc entries to the relevant documentation on https://docs.github.com/en/rest .
• Add tests that cover any added or changed code. This generally requires capturing snapshot test data. See CONTRIBUTING.md for details.
• Run mvn -D enable-ci clean install site "-Dsurefire.argLine=--add-opens java.base/java.net=ALL-UNNAMED" locally. If this command doesn't succeed, your change will not pass CI.
• Push your changes to a branch other than main. You will create your PR from that branch.

When creating a PR:

• Fill in the "Description" above with clear summary of the changes. This includes:
  • If this PR fixes one or more issues, include "Fixes #" lines for each issue.
  • Provide links to relevant documentation on https://docs.github.com/en/rest where possible. If not including links, explain why not.
• All lines of new code should be covered by tests as reported by code coverage. Any lines that are not covered must have PR comments explaining why they cannot be covered. For example, "Reaching this particular exception is hard and is not a particular common scenario."
• Enable "Allow edits from maintainers".