Improve dr$sim config file with template expansion and command line merging

This is a proposal to make it easier to write multi-core config files without duplication, and to make it easier to sweep cache parameters from the command-line while using non-trivial cache hierarchies.

1. Add template expansion to the config file format.
- Suggested format is %{name}, where name is the name of a field in the cache options struct.
- It might be useful to eventually support expressions rather than simple text substitution, but it seems unnecessary for now.
2. Merge the command-line and config-file flows by providing a default built-in config file that is parameterized based on the command-line options.
- Initially this built-in config would represent a 2-level cache hierarchy to replicate today’s command-line-only cache config, but could easily be expanded to support additional configurations based on common command-line parameters, for example swap in a 3-level configuration if the user specifies a non-zero L3 cache size.
- This change implies some means of resolving the priority of options that are specified in the config file: should they override command-line parameters, or only override parameters that were not explicitly set by the user? The latter is the most user-friendly, but it can be tricky to identify options set explicitly vs defaults having the same value.
3. Add a new optional cache parameter called cores_per_cache that specifies the integral number of cores served by the cache. The presence of this parameter having a value >1 implies the cache will be replicated based on the num_cores parameter.
- This change implies a new stage in config processing that resolves the replicated caches and their interconnections.
- A standard naming convention is needed for replicated caches. Suggestion is “.%0#d” where # is the width of the num_cores in decimal. Thus with 80 cores and an L2 cores_per_cache of 2, cores 0 and 1 would be served by L2.00, while cores 2 and 3 would be served by L2.01.
- Cache connections (parent:child relationships) in the config file would use the non-replicated base names.
- While it might at times be useful to support core counts that aren’t evenly divisible by cores_per_cache, that does not seem worth the effort of supporting initially. Instead, such a configuration should be deemed invalid.