Route the forecast estimator's commanded power through the heater PWM chain

SudForecastEstimator.estimate() was feeding tc.get_power() straight to
the plant (pot.set_power(heater_max_power * y)), bypassing the duty-
cycling across the heater's discrete power steps that the real run's
HeaterTask/device chain always applies (tasks/heater.py). That let
pid_heat's own oscillatory tendency reach the plant undamped, so the
forecast showed a violent on/off staircase that no actual brew run
ever produces - confirmed by comparing against real sud_log output,
which stays smooth because the real actuator chain duty-cycles the
same PID output down first.

estimate() now duty-cycles tc.get_power() across the heater's own
power steps (mirroring HeaterTask's PWM logic, duplicated rather than
imported to keep components/ from depending on tasks/) before handing
it to the plant, and also feeds the resulting discretized power back
into the Smith predictor's internal model via set_model_power(), same
as the real wiring in brewpi.py does. The constructor takes the
heater's get_powers() list and the configured sim_warp_factor (needed
to convert HeaterTask's 10-real-second PWM period into simulated
ticks) instead of a bare max power.

server/brewpi.py

@@ -109,7 +109,8 @@ if __name__ == '__main__':
 	# it with the same kind of plant/controller (and params) as above -
 	# see components/sud_forecast.py.
 	forecast_estimator = SudForecastEstimator(
-		DT, theta_amb, config['Controller']['pid_type'], config['TempCtrl'], heater.get_power_max())
+		DT, theta_amb, config['Controller']['pid_type'], config['TempCtrl'],
+		heater.get_powers(), config['Controller']['sim_warp_factor'])
 	sud_task = SudTask(sud, tc, stirrer, pot, DT, DT_TASK, dispatcher.msgio_get("Sud"), forecast_estimator)
 	taskmgr.add(sud_task)
 	# Records every Sud run's measured data and forecast to their own