Update documentation for generating fsurdat/landuse files

[slevis-lmwg]

Description of changes

I started with the README.md already available in /mksurfdata_esmf to update the relevant documentation file.

Specific notes

Contributors other than yourself, if any:

CTSM Issues Fixed (include github issue #):
Resolves #1718
Resolves #3478

Are answers expected to change (and if so in what way)?
No

Does this create a need to change or add documentation? Did you do so?
Yes

Testing performed, if any:

[slevis-lmwg]

@slevis-lmwg note to self: Reminder to also see my updates from a while ago (2023/12/5) to
/doc/source/users_guide/using-clm-tools/what-are-the-clm-tools.rst
in my local branch documentation_wk located in /fs/cgd/data0/slevis/git/latest_master_new.

[samsrabin]

@slevis-lmwg Marking this as draft since it seems like it's still in progress. Please undo that if I'm wrong.

[samsrabin]

One way to make this simpler is to just embed the Markdown file rather than copying it in: slevis-lmwg#18

I agree with @samsrabin I think we should bring in the README file in the embeded way, so that we only have to make changes in one place. This will be easier for maintence. The user's guide could have something additional, and maybe some figures that aren't in the README, but should be supplementary to the README.

[ekluzek]

I think we should pare this down, so it's mostly just the include of the README.md file. That way we just update most of the instructions in one place rather than both. The parts at the top can be the more abstract kind of things that aren't likely to change. So probably just some of the introductory parts at the top would be kept.

We should also think about if we need any figures to illustrate any of the process. I think that was important for mksurfdata_esmf, but may not be as important here. Although I also think some of those prior figures could be adapted to illustrate how mksurfdata_esmf works.

[ekluzek]

@slevis-lmwg and I just went over the changes. We have several things to do, but we don't feel like it needs a re-review afterwards. So approving, and he'll make the changes and bring in when ready.

[wwieder]

@slevis-lmwg should the linked issues on this PR me manually closed?

[slevis-lmwg]

@slevis-lmwg should the linked issues on this PR me manually closed?

I labeled both issues "done" which helps a little, otherwise typically these get closed with the next merge of b4b-dev to master.

[wwieder]

Sorry for the confusion here, I didn't realize these were waiting for b4b-dev to come to master, I just saw the merged icon and assumed they were already there. Marking done for the purposes of the project board seems like a good way to track these?