runtime: do not expand values in evaluateCall()

If we're calling functions in build rules, then it's appropriate to
ActionExpand() arguments. But functions can be called from any phase,
and evaluateCall() doesn't know which phase it's in. It will have to
rely on someone else to ActionExpand() each value in the build phase
-- NOT DONE YET!
runtime: expand function arguments when appropriate (from an action)

Actions should only run in the build phase, so it's fine to do
ActionExpand() from them. And it's consistent: CommandAction was
already responsible for expanding the command string, so it makes
sense for FunctionCallAction to be responsible for expanding function
args.

Fixes the regression introduced by fa1ec190cb9a.
runtime: (temporarily) remove support for keyword args

Since the parser doesn't handle them yet, it seems silly to waste time
making the runtime handle them.
runtime: add build() builtin for defining build rules

Of course you can already define build rules with the special syntax
for them. This is really intended for plugins, which can't be written
in Fubsy syntax; they'll need programmatic access to define build
rules. Supporting it in the DSL is optional, but seems like a nice
touch for completeness.