One of the original motivations for nmrec was to support a feature in
bbr where initial estimates for a new model are inherited from the
final estimates of a previous (typically parent) model.

To make that possible, add set_theta(), set_omega(), and set_sigma()
functions that accept a full parameter value---which is the form that
would come from calling bbr::get_{theta,omega,sigma} on the parent
model---and then map each of those values to the corresponding option
in the parsed records.

Two constraints simplify things from the design standpoint:

 * only support updating parameters that are explicitly written in the
   control stream

   This makes it much easier to stick close to the original form
   because we don't have to drastically alter the control stream, and
   instead are (mostly) working with options that are already there.

   And that also means we don't need complex logic for determining if
   two representations are the same, and deciding what's best to use
   in a given context.

 * only accept the _full_ parameter

   Even though we only update the explicit values, we always require
   the full parameter to be passed, so we don't need provide an
   explicit interface for selecting a sub-part of vector or matrix.

   Note, however, that the caller can still effectively update a
   subset of the explicit values by setting some input values to NA.

Closes #9.

One of the original motivations for nmrec was to support a feature in
bbr where initial estimates for a new model are inherited from the
final estimates of a previous (typically parent) model.

To make that possible, add set_theta(), set_omega(), and set_sigma()
functions that accept a full parameter value---which is the form that
would come from calling bbr::get_{theta,omega,sigma} on the parent
model---and then map each of those values to the corresponding option
in the parsed records.

Two constraints simplify things from the design standpoint:

 * only support updating parameters that are explicitly written in the
   control stream

   This makes it much easier to stick close to the original form
   because we don't have to drastically alter the control stream and
   instead are (mostly) working with options that are already there.

   And that also means we don't need complex logic for determining if
   two representations are the same, and deciding what's best to use
   in a given context.

 * only accept the _full_ parameter

   Even though we only update the explicit values, we always require
   the full parameter to be passed, so we don't need provide an
   explicit interface for selecting a sub-part of vector or matrix.

   Note, however, that the caller can still effectively update a
   subset of the explicit values by setting some input values to NA.

Closes #9.