GuestPortCurrentTel possible refactoring

[jp-pino]

I've been thinking about the GuestPortCurrent message and I think it would be a lot nicer to do:

Proposed

// GuestPort current readings.
message GuestPortCurrent {
  message Currents {
    double vbat = 1;
    double v25 = 2;
    double v5 = 3;
  }

  Currents gp1 = 1;
  Currents gp2 = 2;
  Currents gp3 = 3;
  ...

Current

message GuestPortCurrent {
    ...
    double gp1_24v = 8; // Current on GP1 24V supply (A).
    double gp2_24v = 9; // Current on GP2 24V supply (A).
    double gp3_24v = 10; // Current on GP3 24V supply (A).
    double gp4_24v = 11; // Current on GP4 24V supply (A).
    double gp5_24v = 12; // Current on GP5 24V supply (A).
    double gp6_24v = 13; // Current on GP6 24V supply (A).
    double gp1_5v = 14; // Current on GP1 5V supply (A).
    double gp2_5v = 15; // Current on GP2 5V supply (A).
    double gp3_5v = 16; // Current on GP3 5V supply (A).
    double gp4_5v = 17; // Current on GP4 5V supply (A).
    double gp5_5v = 18; // Current on GP5 5V supply (A).
    double gp6_5v = 19; // Current on GP6 5V supply (A).
    ...

We could do this with a new message and keep the old one in parallel for a while (marked deprecated) with only the 3 old GPs it originally had.
A similar approach could be implemented for the error flags.

@follesoe @johannesschrimpf @sindrehan

Originally posted by @jp-pino in #272 (comment)

[follesoe]

We'll have to keep it in paralell "indefinitely" - or else we could not analyse old log files. Our tooling will have to forever support both formats. I agree it is allot cleaner and has the shape we should have applied initially when designing the protocol. But not sure changing it adds much value since we have to support the old format anway?