Calculations of local noon assume that longitude is 0 to 360 rather than -180 to 180

### Brief summary of bug

SurfaceRadiationMod.F90, PhotosynthesisMod.F90 and UrbanFluxesMod.F90 all calculate the time for local noon, the way it's coded assumes that the grid has longitude from 0 to 360 and NOT -180 to 180.

### General bug information

**CTSM version you are using:** ctsm1.0.dev009

but goes back to ctsm1.0.dev004

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

Because our standard grids are all on 0 to 360 and NOT -180 to 180.

**Configurations affected:** Any with grids on -180 to 180

### Details of bug

Here's a snippet...

```
PhotosynthesisMod.F90: local_secp1 = secs + nint((grc%londeg(g)/degpsec)/dtime)*dtime
PhotosynthesisMod.F90: local_secp1 = mod(local_secp1,isecspday)
PhotosynthesisMod.F90: if (local_secp1 >= (isecspday/2 - 3600) .and. local_secp1 <= (isecspday/2 + 3600)) then
```

### Important details of your setup / configuration so we can reproduce the bug

Also see the cime issue: https://github.com/ESMCI/cime/issues/2778

Here's a note from @swensosc about files that can be used...

"It requires a domain file (and surface data file) with negative longitudes. I've created some here:
/glade/scratch/swensosc/sfcdata/surfdata_0.9x1.25_78pfts_CMIP6_simyr1850_c170824.negative.longitude.nc
/glade/scratch/swensosc/sfcdata/domain.lnd.fv0.9x1.25_gx1v6.090309.negative.longitude.nc
An out of the box f09_g16 clm I case run for 1 month would show the affect."

### Important output or errors that show the problem

It doesn't flag an error, it just silently does the wrong thing.

@olyson @barlage