The `ARDUINO_UNIT_PSTR` macro puts strings in the .progmem.data section,
and set the S (contains zero terminated strings) and M (mergeable)
attributes. Unlike the normal PROGMEM/PSTR macros, which do not set
these attributes, this allows for merging of duplicate or partly
overlapping strings.

However, when the regular PROGMEM attribute is also used, this will put
other variables into the same .progmem.data section, but without these
attributes. The compiler complains about this:

	/tmp/cco2ytva.s: Assembler messages:
	/tmp/cco2ytva.s:2658: Warning: ignoring changed section attributes for .progmem.data

This seems harmless, but effectively causes the SM attributes to be
applied to all progmem data, making the linker believe that all progmem
data consists of mergeable zero-terminated strings, which can cause
problems. For example, when progmem contains any variables with embedded
zeroes, these variables will be truncated at the first embedded zero
(but the code accessing these variables is unchanged, so these will
access data from the next variable instead).

For example, the `port_to_output_PGM` variable for the Arduino mega
(variants/mega/pins_arduino.h) is one such variable, which contains
embedded zeroes and is put into progmem. The following sketch can
reproduce this problem:

	#include <ArduinoUnit.h>

	void setup() {
	  assertTrue(true);
	  digitalWrite(0, LOW);
	}

	void loop() { }

After compiling this sketch for the Arduino Mega2560, the generated
symbol table looks like this:

	$ avr-objdump -t sketch.elf --demangle|sort|grep port_to_output_PGM -A 1
	00000156 l     O .text  0000001a port_to_output_PGM
	0000015d l     O .text  00000056 digital_pin_to_port_PGM

As you can see, the port_to_output_PGM is 0x1a bytes long and should
take space up to 0x156+0x1a = 0x170, but the next variable starts at
0x15d already.

It seems that for other boards, such as the Arduino Uno, these variables
do not contain any embedded zeroes (only leading zeroes, which
apparently are not a problem), so the problem does not surface there.

To fix this, this commit changes the section name used by the
`ARDUINO_UNIT_PSTR` macro to `.progmem.mergeable-strings`, so the
section attribute only affects these particular strings, and not other
progmem data.

The linker scripts used by avr-libc use a wildcard `*(.progmem*)` to
include progmem symbols, so any sections starting with `.progmem` are
included in the link (checked in avr-libc 1:1.8.0+Atmel3.5.0-1 from
Debian that all linker scripts that reference progmem use the wildcard).

This fixes the indentation of the inline assembly, which is messed up by
the previous commit. This is a separate commit, to separate the code
change from the indentation-only changes.

 Put mergeable progmem strings in a separate section

The Arduino IDE requires the use of a single true tab separator between the keyword name and identifier. When spaces are used rather than a true tab the keyword is not highlighted.

Reference:
https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification#keywords

Use correct field separator in keywords.txt

…r *, unsigned int); it has String::append instead.

Fix for 3.0.2 not able to compile for Teensy

This fixes the ARDUINO_UNIT_PSTR macro to not reference the wrong
string. In particular, this makes failing macros not output "passed"
instead of "failed".

The same problem was seemingly the subject of commit 60840b8 (not all
skipped.). That commit fixed the problem for test status by not using
the ARDUINO_UNIT_PSTR macro, and seems to contain a half fix for
ARDUINO_UNIT_PSTR using __COUNTER__, but the way it was used,
__COUNTER__ was never actually expanded, so that did not help (also, it
tried to apply __COUNTER__ in the wrong place).

The actual problem *seems* to be that the `0:` label used to reference
the string constant is not actually unique. It should not need to be,
since the `0b` reference should just reference the nearest label 0,
going backwards, but I suspect that gcc ends up reordering asm blocks
and thus messes up the reference. Using a unique (but still numerical so
local) label seems to fix this. See e.g. this thread about reordering of
asm blocks:

https://gcc.gnu.org/legacy-ml/gcc-help/2017-10/msg00061.html

So, this commit reverts the __COUNTER__ bit from that commit, just using
the plain `ptr` name again (which does not need to be unique, since it
is local the the __extension__ block). It also reverts the changes
around the test status, so these now use ARDUINO_UNIT_STRING again as
originally.

Then, it applies a two-layer macro wrapper for ARDUINO_UNIT_PSTR, that
ensures that __COUNTER__ is actually expanded before being used (which
is needed when using a macro as part of a stringification or
concatenation) and ensures that __COUNTER__ is only expanded once, with
one value, rather than with different values in all three places.

Finally, this commit uses this expanded counter value to generate
unique labels, which seems to prevent this problem from occuring.

Fix incorrect merging of PROGMEM strings

When a test is completed (including failed and skipped), it was already
removed from the "root" list but it is now added to the "done" list.

This allows reusing insert() later to move tests from the done list back
into the active list, without affecting the count.

This simply calls Test::run() until all tests are done.

Allow running tests multiple times