stylix: cleanup mkTarget impl

[0xda157]

inspired by #1368 (comment)

CC @MattSturgeon @Flameopathic @trueNAHO

Things done

• Tested locally
• Tested in testbed
• Commit message follows commit convention
• Fits style guide
• Respects license of any existing code used

Notify maintainers

[Flameopathic]

I'm not sure that the function naming is perfect, but honestly I don't think it ever will be. Code looks nicer now, though! Thanks for the cleanup.

[MattSturgeon]

Do we actually need a function to apply getArgs to a function, when we already have a function to easily get the args?

I.e. is applyArgs foo actually better than foo (getArgs foo)?

I ask, because I'm wondering if it'd be more useful to have a maybeApply, used like maybeApply foo (getArgs foo):

maybeApply =
  maybeFn: args:
  if isFunction maybeFn then maybeFn args else maybeFn;

But I think the current applyArgs would break that abstraction 🤔

[trueNAHO]

Do we actually need a function to apply getArgs to a function, when we already have a function to easily get the args?

I.e. is applyArgs foo actually better than foo (getArgs foo)?

With the previous mkConfig terminology, it seemed obvious to provide this wrapper. Now, it would simplify the code by inlining this applyArgs function.

I ask, because I'm wondering if it'd be more useful to have a maybeApply, used like maybeApply foo (getArgs foo):

maybeApply =
  maybeFn: args:
  if isFunction maybeFn then maybeFn args else maybeFn;

But I think the current applyArgs would break that abstraction 🤔

I think it is better to keep the explicit if builtins.isFunction c then conditionalConfig c else c case in the main loop, as currently done.

[trueNAHO]

Superseded-by: #1721