run_neon base case must be of same run type as a requested clone

[wwieder]

Brief summary of bug

Creating a default NEON case with ./run_neon generates a base case and a transient simulation. Subsequently running with --run-type ad from that original base case fails. Bug is resolved when the base case is created as the same run type as the cases being cloned from it.

General bug information

CTSM version you are using: latest dev tag ctsm5.1.dev115
Thanks to @TeaganKing for first identifying this bug.

Does this bug cause significantly incorrect results in the model's science?

No, but is potentially confusing and frusterating for users

Configurations affected:

NEON single point cases created with .run_neon script

Details of bug

I created a NEON case with the following command, which creates a base case BART and transient case, BART.transient. This simulation runs fine
./run_neon.py --neon-sites BART --neon-version v2

Subsequently cloning a BART.ad case from that base case, however, fails.
./run_neon.py --neon-sites BART --neon-version v2 --run-type ad --base-case BART

These errors can be avoided by creating the base case as the same run type as subsequent clones. For example the following create and runs a ABBY base case that works fine for cloning other .ad simulations

./run_neon.py --neon-sites ABBY --neon-version v2 --run-type ad
./run_neon.py --neon-sites MOAB --neon-version v2 --run-type ad --base-case ABBY

Important output or errors that show the problem

The cesm.log error states

ERROR: (shr_stream_findBounds) ERROR: rDateIn lt rDatelvd limit true

The atm.log error states

(shr_strdata_get_stream_pointer_1d)  strm_ptr is allocated for stream field strm_Faxa_precn
 (shr_stream_findBounds) ERROR: limit on and rDateIn lt rDatelvd
   180101.000000000        20180101.0000000

Definition of done.

In the short term, we can document this in tech note / user's guide, or tutorials for NEON simulations, #1494
Could also be addressed with testing, improvements, and migration of .run_neon into python directory,
#1906, #1441. This could be simply failing to clone a base case that's not compatible with the requested run-type, or backing out the features that are causing this incompatibility in the first place (which is likely harder)?