Refactor development guide

[jhkennedy]

This PR is largely prompted by recent conversations in our hackweeks, #858, and some discussions in the Openscapes slack (e.g., https://openscapes.slack.com/archives/C05TMK269HA/p1730312039229589).

Basically:

• it wasn't clear in our dev guide why you might choose a conda environment, a venv environment, or just use pipx to run nox
• pipx can be as much of a barrier as installing conda/mamba, especially on Windows, so it doesn't feel like a "quick start"
• how to run tests, generally, outside of the pipx discussion wasn't discussed, so the value of nox wasn't clear
• We changed the conda env name but didn't really note it in the docs, leading to some friction

This PR should:

• provide a note that our conda env name has changed and what to do about it
• provide some guidance on which style of dev env (or not) to use
• better explains how to use nox
• provide some guidance on working in an IDE

I think, overall, this should make things more approachable for contributors, but I suspect this proposal may generate some discussion, so it'd be good to get a few reviewer's eyes on this.

I'm happy to make changes -- this is just a starting point IMO.

Note: I do lean heavily into mkdocs syntax, so you may want to view the preview linked below or checkout this branch and build the docs locally while reviewing this PR.

Pull Request (PR) draft checklist - click to expand

• Please review our
  contributing documentation
  before getting started.
• Populate a descriptive title. For example, instead of "Updated README.md", use a
  title such as "Add testing details to the contributor section of the README".
  Example PRs: #763
• Populate the body of the pull request with:
  • A clear description of the change you are proposing.
  • Links to any issues resolved by this PR with text in the PR description, for
    example closes #1. See
    GitHub docs - Linking a pull request to an issue.
• Update CHANGELOG.md with details about your change in a section titled
  ## Unreleased. If such a section does not exist, please create one. Follow
  Common Changelog for your additions.
  Example PRs: #763
• Update the documentation and/or the README.md with details of changes to the
  earthaccess interface, if any. Consider new environment variables, function names,
  decorators, etc.

Click the "Ready for review" button at the bottom of the "Conversation" tab in GitHub
once these requirements are fulfilled. Don't worry if you see any test failures in
GitHub at this point!

Pull Request (PR) merge checklist - click to expand

Please do your best to complete these requirements! If you need help with any of these
requirements, you can ping the @nsidc/earthaccess-support team in a comment and we
will help you out!

• Add unit tests for any new features.
• Apply formatting and linting autofixes. You can add a GitHub comment in this Pull
  Request containing "pre-commit.ci autofix" to automate this.
• Ensure all automated PR checks (seen at the bottom of the "conversation" tab) pass.
• Get at least one approving review.

---

📚 Documentation preview 📚: https://earthaccess--874.org.readthedocs.build/en/874/

[github-actions]

👈 Launch a binder notebook on this branch for commit bc6399e

I will automatically update this comment whenever this PR is modified

👈 Launch a binder notebook on this branch for commit 4f1eb58

[jhkennedy]

Some discussion related to this here:
#872 (comment)

[jhkennedy]

Also, I opened a related discussion here about what we install into our development environments by default:
#875

[andypbarrett]

@jhkennedy I think these changes help a lot.

A few suggestions.

In your comment above you say

pipx can be as much of a barrier as installing conda/mamba, especially on Windows, so it doesn't feel like a "quick start"

I wonder if we should add a note to the pipx tab to say that something along the lines of "Installing pipx on Windows can be a pain, so we recommend using mamba/conda"

Also, should we add a section between the "Development Environment Setup" and "Running Tests" about development workflow and branching? I don't think we can push to main so this seems like a missing step.