dhcptest.options: Fix swapped formats for options 52 and 61

[feiglein74]

The formats for Option Overload (52) and Client-identifier (61) appear to have been assigned to each other's options.

RFC 2132

Section 9.3, Option Overload:

The code for this option is 52, and its length is 1. Legal values for this option are: 1, 2, 3

That is a plain u8.

Section 9.14, Client-identifier:

The code for this option is 61, and its minimum length is 2.

Code   Len   Type  Client-Identifier
+-----+-----+-----+-----+-----+---
|  61 |  n  |  t1 |  i1 |  i2 | ...

That is exactly what OptionFormat.clientIdentifier encodes.

Effect

Neither option could be sent:

--option "52=3"
Error with parsing option: Expected '=' or ':' at position 4

--option "61=01:AA:BB:CC:DD:EE:FF"
Error with parsing option: Unexpected ':' when converting from type string to type ubyte

--option "61=[type=1, clientIdentifier=AABBCCDDEEFF]"
Error with parsing option: Unexpected '[' when converting from type string to type uint

Received packets were affected too. Option 61 threw and fell back to hex, and option 52 silently rendered a legal value of 3 as meaningless but plausible-looking output:

Option	Data	Before	After
52	03	type=3, clientIdentifier=	3
61	01 AA BB CC DD EE FF	throws u8 must be 1 byte, hex fallback	type=1, clientIdentifier=AA BB CC DD EE FF

After the change all three forms parse, including the RFC's hardware-type-0 case for non-hardware identifiers:

--option "52=3"                                              -> 34 03
--option "61=[type=1, clientIdentifier=AABBCCDDEEFF]"        -> 3D 01 AA BB CC DD EE FF
--option "Client-identifier=[type=0, clientIdentifier=6D79686F7374]" -> 3D 00 6D 79 68 6F 73 74

Tests

Two unittests added, following the style of the existing per-option tests. dub test passes with both LDC 1.42.0 and DMD 2.100.0 (the version pinned in CI).