SerialServer: allow clients to be non-sequential

[chrisguikema]

This commit adds a helper function to get a client structure based on the badge. The allows for clients to be numerical, but not sequential, and guarantees serial input will always align to the correct client on each build.

A side-effect of this method is that the clients are switched to by typing the ESCAPE_CHAR + badge number. This limits the number of clients to single-digits, 0 -> 9.

[chrisguikema]

From previous PR:

"Decoding badge numbers into getchar client IDs isn't safe unless client ID value 0 is reserved, which this change doesn't appear to be doing. The simplest approach that I can think of is to allow a string to be assigned to each client in the connection configuration (or just take the name of the instance+interface) and then allocate the getchar client IDs based on a lexicographical order of all the clients. This should provide a stable ID assignment across builds, and still allow badges to be allocated internally (where it can be ensured that badge 0 isn't used)."

This hasn't been addressed yet, but I will handle it properly.

[chrisguikema]

@kent-mcleod I think i've addressed the zero badge issue. I guess it was an issue before this PR, so if you want to recommend any other changes, I'll be happy to implement.

I also updated the corresponding PR in camkes-vm to align each serial server connection.

[kent-mcleod]

@kent-mcleod I think i've addressed the zero badge issue. I guess it was an issue before this PR, so if you want to recommend any other changes, I'll be happy to implement.

I don't expect that it was an issue before? The templates were generating badges >= 1 and then the init logic was assigning them to clients based on enumeration order rather than badge value.

    /* query what getchar clients exist */
    if (getchar_num_badges) {
        num_getchar_clients = getchar_num_badges();
        getchar_clients = calloc(num_getchar_clients, sizeof(getchar_client_t));
        for (int i = 0; i < num_getchar_clients; i++) {
            unsigned int badge = getchar_enumerate_badge(i);

(Although, if you manually set the badge to 0 via the *_attributes setting in the camkes configuration, then you could get a client with a badge value of 0).

[chrisguikema]

I more meant that the putchar interfaces would simply use the raw badge number, so if the badge was always > 1, then the first color in the color array wouldn't be used?

[chrisguikema]

Yeah, I just tested without these changes, and Green/Blue were the colors being used (not Red). And the colors used by the VMM and VMs were inverted, which could be a bit confusing.

[axel-h]

Could you add a note in the code here, what drives this limit? I think it would help to get the background for people new to the code. Increasing this is not trivially possible.

[axel-h]

Maybe make -1 and -2 a dedicated define now, so this is a bit more transparent, what magic values exist.