Low: fix compiler's complaints about possibly unaligned pointer access

In function ‘format_peers’: main.c:230:14:
warning: taking address of packed member of ‘struct booth_site’ may
result in an unaligned pointer value [-Waddress-of-packed-member]

230 |    localtime(&s->last_recv));
    |              ^~~~~~~~~~~~~

In function ‘booth_tcp_open’: transport.c:656:42:
warning: taking address of packed member of ‘struct booth_site’
may result in an unaligned pointer value [-Waddress-of-packed-member]

656 |  rv = connect_nonb(s, (struct sockaddr *)&to->sa6, ..., ...);
    |                                          ^~~~~~~~

In function ‘message_recv’: transport.c:1108:7:
warning: taking address of packed member of ‘struct booth_site’
may result in an unaligned pointer value [-Waddress-of-packed-member]
1108 | time(&source->last_recv);

|       ^~~~~~~~~~~~~~~~~~

and

In function ‘store_geo_attr’: attr.c:282:13:
warning: taking address of packed member of ‘struct geo_attr’ may
result in an unaligned pointer value [-Waddress-of-packed-member]

282 |    get_time(&a->update_ts);
    |             ^~~~~~~~~~~~~

timer.h:43:48: note: in definition of macro ‘get_time’

43 | #define get_time(p) clock_gettime(BOOTH_CLOCK, p)
   |                                                ^

In function ‘append_attr’: attr.c:337:18:
warning: taking address of packed member of ‘struct geo_attr’ may
result in an unaligned pointer value [-Waddress-of-packed-member]

337 |  if (is_time_set(&a->update_ts)) {
    |                  ^~~~~~~~~~~~~

attr.c:338:16: warning: taking address of packed member of
‘struct geo_attr’ may result in an unaligned pointer value
[-Waddress-of-packed-member]

338 |   ts = wall_ts(&a->update_ts);
    |                ^~~~~~~~~~~~~

The solution for the affected, historically packed structs (which is
the trigger of the possible unaligned access in the first place),
assuming we want to carry on with this binary terseness, is that
we assure the struct itself is always aligned per its first member.
This first member is hence automatically guaranteed to be aligned
just as well, and shall there be any other address-of referenced
members, they immediately follow (rule being that these are ordered
from the biggest natural alignment to the lowest, for which C11
_Alignof operator is used).

We build on already established assumptions that data declarations
are readily controllable with non-standardized attribute annotations.
Shall this (or reliance on C11 construct, but hey, it's 2020) be in
violation with universality (it apparently hadn't been so far), both
"packed" and "aligned" are to be to be conditionally dropped together
(which will also restore no-complaints state as a side effect).

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>