Add support of forks and authorization token

[f0nar]

Hi and sorry that I barge in like this)

For the last few months I have been actively working with GDevelop and its improvement and I found your tool very convenient.

This PR adds two main features

• authorization token support for octokit request api to increase API limit rate

loadGD({
    authToken: "your private github token",
})

• support of loading GDevelop sources from forks
  I added user option to redirect to forks. Loading of Runtime sources is pretty easy task in this case but storage of libGD assets is a more specific thing. E.g. in my case I attach them to release. I added few options to improve flexibility

// helps in my case. simply check assets attached to `versionTag` release
loadGD({
    user: "f0nar",
    versionTag: "pixi-spine-commitment",
    fetchProvider: {
      useReleaseAssets: true,
    },
});

// case if you publish assets to some storage
loadGD({
    user: "f0nar",
    versionTag: "pixi-spine-commitment",
    fetchProvider: {
      libGDPath: `https://some/url/to/published/libGD/assets`
    },
});


// case if you need more complicated functionality to load these assets
loadGD({
    user: "f0nar",
    versionTag: "pixi-spine-commitment",
    fetchProvider: {
      'libGD.js': (gdPath) => downloadAsset(gdPath, 'libGD.js'),
      'libGD.wasm': (gdPath) => downloadAsset(gdPath, 'libGD.wasm'),
    },
});

I want to say that I did not break old API structure

// It is still possible to pass release tag only
loadGD("v5.3.158");
// or nothing at all
loadGD();

P.S. During my changes code grew so much so I allowed myself to split it by different files. Hope that is ok)

Here is exporter PR arthuro555/gdexporter#9

[f0nar]

Oh in addition I was in hurry and it is late here already so typos may occur. I will check them tomorrow)

[f0nar]

@arthuro555 Hi! Is there a chance that you can review this PR?
I would really appreciate it

[arthuro555]

Sorry for my lack of reactivity, I am kind of hesitant to add this. I feel like for forks, it is not a good idea to use this. Currently, some of the GDevelop code is embedded in the repository, and needs to be updated with GDevelop updates. As such, if GDevelop diverges from the fork in these aspects, this will break on forks.

Generally, my vision as well was to remove the dynamic fetching of GDevelop runtime code, instead opting for obtaining this GDevelop code from the GDevelop repository at build time, and to release a version of the package on NPM with an embedded GDevelop runtime & GDCore for the latest versions of GDevelop, re-releasing a new package for every GDevelop update.

My recommendation would be instead to fork this repository, replace references to upstream GDevelop with your own repository, and to publish your own fork of the package on npm for usage in your projects.

[arthuro555]

Closing this now, since I have opened the PR for V2.
You can use gdcore-tools with your own fork by following these steps:

1. Clone gdcore-tools's 2.0.0 branch next to a folder called GDevelop containing your own fork:

gdcore-tools
|- package.json
|- ...
GDevelop
|- newIDE
|- GDJS
|- ...

2. Change the name of gdcore-tools in package.json to be scoped to your npm organisation: gdcore-tools -> @f0nar/gdcore-tools
3. Run npm install then npm publish in the gdcore-tools folder. The build scripts will create a gdcore-tools package for your own GDevelop fork automatically, and will publish it to your npm organisation.
4. From there, you can simply install and use the @f0nar/gdcore-tools in your other projects.