Add fetch support for different Artix init systems

[unrooted]

I think that we should use the possibilities which Artix Linux gives us, and I strongly believe that users would appreciate an option to install an init system of their choice when they fetch Artix strata.

I've checked all of those, worked on my Bedrock VM. Not only that, but I was able to use all of those as init strata as well.

Hope that this will see a positive impact and use throughout our community. It ain't much, but it's honest work.

[paradigm]

This PR:

• Adds a lot of code (512 lines!) and associated maintenance.
• Adds a lot of noise to brl fetch -X.

Which isn't ideal. I'd prefer any of the following alternatives:

• One of the many long-standing plans for Naga is to give brl fetch a --flavor flag to select things that need to be selected at distro install time even with minimal installs. This includes things like Void's musl vs glibc choice and, for Artix, init selection. My plan for this feature set was to wait for that. We could stick with that plan.
• I understand Arch's insistence on its minimal install having an init, given that this allows the rest of the code base makes assumptions around that specific init. Artix's init flexibility here means no such assumptions, thus it seems odd to me that its minimal install (base) apparently requires an init (indirectly through base requiring init-logind). It's not as though this minimal instance needs to be self-sustaining, as base does not require a kernel. We could investigate the possibility of an even more minimal install option that lacks an init, in which case brl fetch just needs to support the minimal Artix and users can pacman -S whatever init they want.
• We could just stick with the default init that base pulls in and expect users to reference Artix documentation for switching inits.

it's honest work

Given our repeated, lengthy discussions about not adding unnecessary work to Poki which would delay Naga and the fact you prefaced this PR with

so, para will probably punch me

your honesty here is debatable.

[unrooted]

I've made it using already existing fetch support for artix-s6 just by modifying the basestrap part, hence the crazy number of lines.

When it comes to maintenance - I'm already an Artix maintainer, so the responsibility for that lies on my shoulders, and I'm totally OK with that.

I must agree with your approach to the issue. Right now it's quite messy and brl fetch [strata] --flavor approach sounds good. We can wait, but I guess it's more than OK to come back to this in future and use the full potential of Artix. I really hope this happens.

Referencing Artix documentation is also a good approach, however, I guess it'd be handy for our community not to tinker with it that much and just use fetch scripts once they're done. But again, no rush, I like the --flavor idea. My PR is just a suggestion, sorry if that puts pressure on you - that wasn't my intent.

I can devote a bit of time to investigate the minimal Artix strata approach if it will be required. Maybe we can turn this into a --flavor as well and call it minimal?

And, just a note: no, this is not a PR I've meant when said that you will 'punch me'. After yesterday's discussion on our IRC about community scripts/modules/call it as you like, I've decided not to. For now, I'll keep it for myself, because my idea when speaking about that was to add some usability enhancements scripts to Bedrock and custom, which are mostly messy (and debatable in terms of actual usability) PoCs, rather than actual full-fledged features made for Bedrock. However, we (people on IRC, I guess) have agreed to wait for .8 and the feature with hooks for custom scripts/modules and not make further noise around it. So, tl;dr: no, this is not the thing I've meant.

Sorry if there might have been a communication breakdown between us, but I had good intentions with this PR right here, and sorry if I was misunderstood with my goals. I always have good of Bedrock, and it's community in mind.

[unrooted]

@paradigm hi, can I delete my fork of this repo?

I have to admit that the approach I've suggested wasn't thinked through enough at that time and creates a lot of unnecessary noise, to both lines of codes, and future maintanance of this.

What is more, I suppose there won't be a need for the approach I've suggested 2+ years ago, there are more important things to do, as well as we can always get back to it, once Naga rolls out and there'd be --flavor option (of course - if you still consider it)