Configs: use a uniform syntax without Match exceptions

[terpstra]

The old style of specifying Configs used total functions. The only way to
indicate that a key was not matched was to throw an exception. Not only was
this a performance concern, but it also caused confusing error messages
whenever you had a match failure from a lookup within a lookup. The
exception could get handled by an outer-lookup that then reported the wrong
key as missing.

[hcook]

Closes #506

[hcook]

No one was using the Map[Any,Any] part of the API anyways.

[jchang0]

Can we do some kind of depreciation for CDEMatchError instead of removing it altogether for the time being? (not even sure if it's possible to depreciate a class)

[terpstra]

We could, but it is only used in Config definitions, which need to be refactored anyway.

[hcook]

To expand on @terpstra's comment, all instances of
class BasePlatformConfig extends Config(
(pname,site,here) => pname match {
case Foo => 2
case _ => throw new CDEMatchError
})
become
class BasePlatformConfig extends Config( { (site,here up) =>
case Foo => 2
})
This is a mandatory backwards-incompatible upgrade, one of several coming this week :D

[colinschmidt]

Wait does the config package not use exceptions for control flow?