ignore_ic_* options to build-namelist and IC selecting process needs some love

### Brief summary of bug

There are currently two options to build-namelist for changing how initial conditions (finidat files) are selected. -ignore_ic_date and -ignore_ic_year. I don't think users normally actually set either of them, they are picked for you in buildnml. They came from how CAM was doing IC selection, but doesn't quite work with what CTSM needs to do. For CAM the starting year usually meant nothing, so having it as default made some sense. For CTSM with Crop though ignore_ic_date, is problematic because of the counters that determine crop management. So you can't really use that for crop. And for CTSM for transient cases, the year is meaningful, since that's what the landuse should be set to. But, for control cases, the year is meaningless, and you need to go by the "sim_year". So these should be set for you, rather than expecting the user to be able to figure this all out. It's possible there might be a reason for the user to override it -- but I'm not convinced on that.

So the ignore settings are one thing, another is how the IC selection is done. It needs to be done in such a way that you get the right land-use year, and we want that to be solid for both transient and control cases.

This is related to #544 and really is the underlying cause of it.

### General bug information

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

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

**Configurations affected:** The problem in #544 has to do with cases coupled to CAM.

### Details of bug

The ignore command line settings should be moved to internal to CLM buildnamelist. We should decide if the user really would ever have a reason to override them or not. If not, they should be removed as a user setting. Then we need to make sure the mechanism to pick the land-use year is robust and works for both control and transient. Then I think there's some code cleanup that can happen to make the logic clearer as well as more robust.

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

See #544