vwegolf: set the pre-conditioning target temperature (BC_SET_TEMP)

[Nueueuet]

Follow-up to #1496, as suggested by @SCjona: the one BatteryControl setting his
module could not change yet.

BC_SET_TEMP is shaped like his BC_SET_CURRENT — read profile 0, change one
field, write it back, confirm on the write echo, no trigger. Only the
temperature byte moves; the operation byte is left exactly as the car has it, so
it can neither start nor stop anything. The raw profile encoding
(degC * 10 - 100) goes in as the command param so it fits the existing
uint8_t: 15.5 °C is 55, 30.0 °C is 200.

Three places needed the new op alongside BC_SET_CURRENT, so they share an
IsSettingsEdit() predicate now: the post-arm phase choice, the lost-echo retry,
and the skip-write optimisation. That last one is the one that bites — it
compares only the operation byte, so a temperature-only edit looks like a no-op,
nothing is written at all, and the trigger fires anyway. Confirmation also lives
inside the BC_SET_CURRENT branch of the write-echo handler; without its own the
command never completes and re-arms every two seconds until the window closes.
Both are worth a suspicious look from whoever knows that state machine.

Two commands come with it, since the target temperature is not carried by the v2
protocol and cannot be read app-side from metrics:

xvg cctemp <15.5..30.0>   set it, snapped to the half-degree steps
xvg ccstatus              cctemp=22.0 current=32 valid=1

valid tests the temperature against 0, per @SCjona's suggestion: below 10 °C is
not encodable, so 0 can only mean "not read yet".

Does the BCU apply it mid-run?

@SCjona expected it to behave like the charge current, which a running charge
ignores until the next start. It does not — the setpoint is picked up while
conditioning runs, so there is no re-fire. Measured on a 2016 e-Golf, plugged in,
28 °C ambient, v.e.cabintemp polled every 20 s:

window	target	cabin	rate
1:23 – 5:00	30.0 °C	35.2 → 34.5 °C	−0.19 °C/min
5:43 – 7:23	16.0 °C	34.0 → 30.3 °C	−2.2 °C/min

Three and a half minutes at a 30 °C target with a 35 °C cabin and it barely
moved. About 40 s after the write the curve bends and the cooling rate goes up
tenfold. The reverse, in a second run:

window	target	cabin	rate
0:22 – 3:43	16.0 °C	31.0 → 26.7 °C	−1.3 °C/min
4:03 – 10:00	30.0 °C	26.7 → 28.4 °C	+0.29 °C/min

Cooling to heating, no restart, same ~40 s latency. Both runs are in the log with
the 49 59 bx write echoes; v.e.hvac stayed set throughout and the only
49 58 00 -> HVAC OFF in either came from the stop command. This contrast is
documented in bat-ctrl-bap.md next to the charge-current note.

Notes

• Two small additions keep the native tests building: the mock's OvmsWriter
  gained puts/printf and OvmsMetric an AsInt(), both used by ccstatus,
  and vehicle_vwegolf.cpp now includes <cmath> for lroundf instead of
  picking it up transitively as it does on the target. 136/136 pass.
• One earlier version of this commit also carried a change to
  TransmitMsgCapabilities(). That is a separate concern and is now Server V2: advertise capability C26 so the app can offer climate control #1506.