Respect bounds when using Solver::Options::check_gradients

When Solver::Options::check_gradients is true, Ceres internally
creates a new ProblemImpl object which wraps each CostFunction
in the user's problem with a GradientCheckingCostFunction.

Doing this also requires creating new ParameterBlock objects,
and when support for upper and lower bounds was added to Ceres,
CreateGradientCheckingProblemImpl should also have been updated
to create a problem with the same parameter bounds. As a result,
if check_gradients is enabled for a bounded problem, it constructs
an unconstrained problem and solves it.

This CL fixes this, by introducing Problem::GetParameterLowerBound,
and Problem::GetParameterUpperBound and using them to create a bounded
problem when checking gradients.

Thanks to @pbeeson for not only reporting this problem, but also
providing a small standalone reproduction which made debugging this
possible.

https://github.com/ceres-solver/ceres-solver/issues/379

Change-Id: Id18eb858a7009bf4fa452a21b925922d13f3249f

internal/ceres/gradient_checking_cost_function.cc

@@ -211,6 +211,17 @@ ProblemImpl* CreateGradientCheckingProblemImpl(
       gradient_checking_problem_impl->SetParameterBlockConstant(
           parameter_block->mutable_user_state());
     }
+
+    for (int i = 0; i <  parameter_block->Size(); ++i) {
+      gradient_checking_problem_impl->SetParameterUpperBound(
+          parameter_block->mutable_user_state(),
+          i,
+          parameter_block->UpperBound(i));
+      gradient_checking_problem_impl->SetParameterLowerBound(
+          parameter_block->mutable_user_state(),
+          i,
+          parameter_block->LowerBound(i));
+    }
   }
 
   // For every ResidualBlock in problem_impl, create a new