Tweak behaviors of build and release CI workflows

[altheaden]

Description

Hello! With this PR I've tweaked some settings that @xylar and I have determined work out better in CI workflows on other repos. I've made the same changes here. These changes include:

1. cancel_others is now set to false by default, which should make it easier to decipher if a bug is isolated to a specific version of python via CI
2. All references to mamba/ Mambaforge have been removed and/or changed to conda / Miniforge3
3. The timeout for the pre-commit job has been upped to 5 minutes (we were having some timeout issues during the caching step)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[xylar]

@altheaden, it looks like cancel others is still on here. Do you want to change that, too? Then, we can ask @tomvothecoder and @chengzhuzhang what they think of the changes in general.

[altheaden]

@xylar Whoops, definitely a mistake, thanks for catching that! Fixed.

[xylar]

@altheaden, thanks for the latest change. This looks great to me!

@tomvothecoder, @forsyth2 and @chengzhuzhang, please have a look when you can. The change from Mambaforge to Miniforge3 should be straightforward because Mambaforge and the mamba command just aren't supported anymore as a separate thing (though they still exist for backwards compatibility).

We had some recent mysterious failing CI and it took us awhile to realize that caching can sometimes take more than 2 minutes so we suggest upping the timeout.

And finally, as @altheaden says above, we have found it more frustrating than helpful to have all the CI runs get cancelled when one fails. It's often good to know if the same problem persists across different builds or if it's specific to one (e.g. one version of python). We don't typically save a lot of cloud computing time either by canceling because the CI might not need to rerun if it were to succeed and it would typically fail around the same time as it gets cancelled if it were to fail.

[xylar]

One more note, if you're happy with these changes, @altheaden will make similar ones for zppy and zstash.

[forsyth2]

@altheaden Thanks for working on this!

@xylar From visual inspection alone, these changes seem fine for zppy and zstash too, thanks.

[xylar]

Great, let's make sure @tomvothecoder agrees since he wrote these workflows in the first place.

[tomvothecoder]

Hi @altheaden and @xylar, these changes look reasonable to me. I'm happy to have this PR merged. Thanks @altheaden!

[xylar]

@chengzhuzhang, it sounds like you can merge then if you're also happy.

[chengzhuzhang]

It looks good to me. Thank you for this update @altheaden @xylar !