Add support for Eureka service registration

[barchetta]

This issue attempts to capture a problem description and a few hard-and-fast requirements of work around Eureka service registration. The following is an initial draft of the shape of the work, and is subject to edit and change at any time:

Who

A developer of a Helidon-based microservice

Wants To…

Have her microservice's coordinates (host, port, etc.) appear in a preëxisting (probably Spring-based/flavored) Eureka server somewhere such that developers of other microservices, Helidon-based or otherwise (probably Spring Boot-based), can discover it from that server, using Eureka-flavored facilities they are familiar with (probably Spring Cloud's DiscoveryClient machinery)

Goals of the Solution

• Configuration only. The Helidon developer should ideally have to add only a minimum of configuration to her microservice, and perform no other work, to accomplish her goal
• Spring-friendly. The primary beneficiaries of this work will be Spring Boot/Spring Cloud users who will be able to "see" Helidon-based microservices in the Eureka service catalogs they are used to interacting with. It is not an immediate goal to support other kinds of consumers.

Non-Functional Requirements

• The version of Eureka involved will be 2.0.4 (the version used, and at least partly maintained, by Spring Cloud Netflix machinery version 4.2.0)
• No third-party HTTP clients should be used

Issues

• The REST API for Eureka server is not documented and must be reverse engineered from the Eureka source code and its interaction with the default behaviors of the version of Jackson it uses for JSON marshaling (see also Possible discrepancy between documented REST operations and actual serialization/deserialization? Netflix/eureka#1563)
• This work is dependent on a way for abstract event listeners of some kind to be informed when the Helidon webserver is up and running. PR Adds an afterStart pseudo-event to LoomServer observable by Router implementations #9655 begins to address this.