Update src/lfe_eval.erl (eval_{match_,}lambda/2)
Update src/lfe_eval.erl (eval_{match_,}lambda/2)

I was curious about Elvis, the Erlang style reviewer, and needed a large
body of Erlang code on which to run it, so I figured, what better
codebase than LFE? In doing so, I got a bunch of boring warnings about
spaces after commas and such, but the DRY warnings caught my eye. Elvis
pointed out that eval_lambda/2 and eval_match_lambda/2 were very
similar, so I decided to have a go at reducing the redundancy.

I'm not sure if this is a good approach, or if it makes any meaningful
difference to lambda evaluation, but I've removed eval_lambda/2 as well
as eval_match_lambda/2 and replaced them with eval_lambda_expr/2.
I picked a new name to avoid potential confusion.

Some observations of the two functions:

1. They called different functions (with different arities):
   apply_lambda/4 vs apply_match_lambda/3
2. The last two arguments passed were the same: Vals and Env
3. eval_match_lambda uses match_lambda_arity/1 instead of length/1 to
   determine the arity.
4. Obviously, lambda forms have arglists and match-lambda forms have
   clauses.

The case analysis on line 340 returns a tuple of the
appropriately-determined arity and a function that takes Vals and
returns a call to apply_{match_,}lambda.

Next, the case analysis of Arity, much like before, returns functions
of the appropriate arity that call the previously created Vals-consuming
functions accordingly.

This really isn't a big change, but it's sort of nice to handle both
types of lambda expression in the same place and net deletion of 41
lines feels good.

    $ git diff --shortstat --cached src/lfe_eval.erl
     1 file changed, 34 insertions(+), 75 deletions(-)

P.S. I love these comments:
%% This is a really ugly hack! But it's the same hack as in erl_eval.

Elvis: https://github.com/inaka/elvis

rvirding/lfe,jjhoo/lfe,lfe/lfe,lfe/lfe,jjhoo/lfe,rvirding/lfe