Add LwIP Ethernet example using tap network driver

[lschuermann]

This adds an example application running an LwIP-based TCP/IP network
stack and HTTP server based on the EthernetTapDriver kernel capsule,
and the streaming process slice abstractions.

It includes commits from the following other PRs, which I will remove
once they have been merged:

• libtock: add util/streaming_process_slice #492: libtock: add util/streaming_process_slice
• Configuration.mk: add TOCK_TARGETS for QEMU rv32 virt board #493: Configuration.mk: add TOCK_TARGETS for QEMU rv32 virt board

[lschuermann]

@bradjc @ppannuto I couldn't figure out how to exclude the lwip/lwip submodule from the formatting pass. I assume I'm missing something obvious, as it does work for all the other submodules...

Formatting ./lwip_ethernet_tap
../../lwip/Makefile:14: ../../lwip/lwip/src/Filelists.mk: No such file or directory
make: *** No rule to make target '../../lwip/lwip/src/Filelists.mk'.  Stop.
 ⤤ Failure formatting ./lwip_ethernet_tap
Rebuilding Verbose: ./lwip_ethernet_tap

[bradjc]

@lschuermann

libtock-c/u8g2/Makefile

Lines 25 to 26 in 14e590a

	# Avoid failing in CI due to warnings in the library.
	override CPPFLAGS_$(LIBNAME) += -Wno-error

[bradjc]

Need a https://github.com/tock/libtock-c/blob/master/lvgl/Makefile.setup and can you add a readme to the libtock/util folder to explain what goes in it? I assume we want it to be only be utilities related to abstractions provided by the tock kernel.

[lschuermann]

@lschuermann

libtock-c/u8g2/Makefile

Lines 25 to 26 in 14e590a

	# Avoid failing in CI due to warnings in the library.
	override CPPFLAGS_$(LIBNAME) += -Wno-error

@bradjc Still doesn't fix the formatting errors on the lwip submodule, unfortunately. Any hint on how to disable uncrustify for the submodule?

[brghena]

Some small things and reminders. But this is just about ready to go once you have time to update it.

[ppannuto]

Okay, I believe all the make/build nonsense should be fixed. One thing I'm not 100% sure is okay is 3552552, but I don't really know what else to do here.

I think it's okay because newlib doesn't undef before trying to define BYTE_ORDER, so hopefully if there were ever a conflict due to include ordering, it'd show up as a redefinition warning?

[brghena]

Two more small nits

[brghena]

Looks good to me. This is a really great addition to userspace.

[brghena]

This is ready to go. So if anyone still has opinions, please comment soon.

[lschuermann]

@brghena Fixed a small indentation mismatch in the README.