upload nightly to deken, manual upload setting for release

[ben-wes]

this removes the deken upload logic for release runs and just expects the checkbox in the manually dispatched run (seems more elegant and logical anyway):

besides that (and more importantly), nightly builds are also uploaded to deken - as suggested in #111 (comment). the version is derived the same way as for releases, but an additional -nightly suffix is added. the result looks like this (these were my test runs and i removed the packages again):

this works pretty well; the only issue that i see is that users will probably install the nightly version by default - the deken app has preference toggles to only display the latest version and only for the system architecture. with these set, the result looks like this (but it's obviously exactly the same for Gem snapshots):

to properly run, this requires flucoma/actions#8 and a v6 tag on the actions side.

[umlaeute]

just a sidenote (and I didn't see this PR, so I started #119 which is in the same vein):

as the admin of the deken server, i see that people are searching for flucoma.
i'm afraid that the amount of people who search for "fluidcorpusmanipulation" is rather small (obviously @ben-wes did a search; there were two more in the last 2 month as well)

[ben-wes]

obviously @ben-wes did a search

there should be quite a few of my "fluidcorpusmanipulation" (or truncated with wildcard) searches in the logs from the times i tested the deken upload. :)

i agree with #119 by the way. when first installing it, i was confused about the directory name since i also expected flucoma - in line with how i heard people refer to it. also, lowercase seemed more consistent with most other libraries - except for Gem. ;)

so for "SEO" reasons (and based on your deken insights), naming it flucoma certainly seems better. i actually had it that way at some point when working on #111, but then changed it again to avoid breaking changes for patches with [declare -path FluidCorpusManipulation -lib fluid_libmanipulation] (and for users with Pd's path preferences set accordingly).

i don't have a strong opinion right now - but i'll gladly adapt this PR if needed.

EDIT: if there's a decision to add breaking changes, the name of the library binary might also be questioned (i would have expected flucoma there as well). but i added a README.deken.pd with #111 that explains this stuff and also provides a (hacky) way of simply adding the library path via a add-to-path message.

[umlaeute]

i don't have a strong opinion right now

me neither :-)

my entire interaction with this team was merely triggered by a recent glance at the deken log files to look for patterns in search result that don't returned any results (in the very late wake of this thread), and flucoma showed up a couple of times (I didn't notice fluidcorpusmanipulation until i actively search for it)