RFC: adopting forgejo-aneksajo for DataLad versions of dandisets + issue tracking etc.

ATM github is used for a number of purposes in the project
- authentication into archive
- code, documentation, and infrastructure management development
- helpdesk support for our users: https://github.com/dandi/helpdesk
- (managed outside of dandi-infrastructure) replication of dandisets and zarrs as DataLad datasets on https://github.com/dandisets and https://github.com/dandizarrs

we contemplated also
- use of github for issue tracking etc based on individual datasets on https://github.com/dandisets in https://github.com/dandi/dandi-archive/pull/1595

That development of issue tracking has stalled in part because reliance on external commercial service (github) potentially complicates "roll out" of "platform as a whole" and might be jeopardized by terms and conditions of the service (e.g. by limits on sizes etc). That is why I am actively considering RFing our "datalad"ification to serve DataLad (git/git-annex) versions on dandisets on managed by us instance of https://codeberg.org/forgejo-aneksajo/forgejo-aneksajo . You can find listing of existing, sciencey deployments on

- https://github.com/datalad/datalad-usage-dashboard/issues/47

Additional benefits for going with that solution instead of github would be ability to customize
- its look / branding
- adding additional handlers for data types of interest to us, e.g. see
- watching videos right from the portal: https://hub.datalad.org/distribits/recordings/src/branch/master/distribits2024/2024-04-04_01_welcome_day1.webm
- visualization of metadata extracted for files or adding additional viewers etc, not alike we already do in "Open With": see e.g. https://hub.datalad.org/test-resources/nifti1-testdatasets/src/branch/main/avg152T1_RL_nifti.nii.gz page
- adding CI execution which would be under our control and thus could be much more scalable/involved

In principle, then that's where we could implement workflows for accepting data as well, doing validation and review etc. May be even allowing individual users/labs to have their own forks for the dandisets etc.

Potentially eventually may be even providing a complete alternative to ad-hoc dandiarchive.org web UI, and relying on community developments in that platform.

Authentication sources include OAuth2