tighten up /etc/rc.conf regex

I've run into a fun issue on FreeBSD 10 when trying to disable `syslogd`,
and enable `rsyslogd`.

Initially, the /etc/rc.conf config file may look something like this

    syslogd_enable="YES"
    rsyslogd_enable="NO"

And after chef it *should* look this

    rsyslogd_enable="YES"
    syslogd_enable="NO"

However, because the regex isn't as tight as it could be, it will search for
`syslogd_enable="(\w+)"`, and erroneously match the `rsyslogd` line, which leads
Chef to believe that `syslogd` is enabled, when in reality it isn't.  This change
simply anchors the regex with `^` so the pattern must match at the beginning of
the line.

PS: This is my first time submitting a change to Chef after the move off of Jira, but I've already signed the CLA and am number 753 on the approved contributors list.
So, interesting situation.  As it turns out, any `sh(1)` syntax is valid in this configuration file, so as a result any leading (or trailing) whitespace is valid.

However, assuming variable assignment is done only once could be potentially problematic. For example imagine a (contrived, but completely valid) `/etc/rc.conf` config like this

``` sh
if hostname | grep -q syslog; then
  syslogd_enable="YES"
else
  syslogd_enable="NO"
fi
```

Now, imagine we want chef to turn on `syslogd` on all machines, so we write something like this:

``` ruby
service 'syslogd' do
  action :enable
end
```

As it is currently in the master branch, Chef will delete any lines pertaining to the service, and add a new variable declaration at the bottom of the file.  This will cause the file to now look like this:

``` sh
if hostname | grep -q syslog; then
else
fi
syslogd_enable="YES"
```

Which now has a syntax error, as `sh(1)` doesn't allow for empty `if` bodies.

With this PR however, Chef will make the file look like this:

``` sh
if hostname | grep -q syslog; then
  syslogd_enable="YES"
else
  syslogd_enable="NO"
fi
syslogd_enable="YES"
```

which, even though awkward, will yield the intended result because the last variable declaration will win.

Allowing for leading whitespace will create the same issue that exists currently in master.

The *real* solution would be to parse `sh(1)` syntax and to be able to understand what exactly *will* happen, but that is just completely outside of the scope of what Chef should do.  I say if a user adds this kind of shell logic into their `/etc/rc.conf` file they are on their own, so chef should just avoid it (by not matching leading whitespace) and dump new file contents at the bottom of the file, as opposed to result in a syntax error, which typically requires booting the OS in singleuser mode to fix.