changed layout of inline code

Issue microprofile#222

Signed-off-by: Ralph Soika <ralph.soika@imixs.com>

README.adoc

@@ -43,7 +43,7 @@ A detailed description of the health check protocol can be found in the link:htt
 
 === API Usage
 
-The main API to provide health check procedures on the application level is the `HealthCheck` interface:
+The main API to provide health check procedures on the application level is the _HealthCheck_ interface:
 
 ```java
 @FunctionalInterface
@@ -53,9 +53,9 @@ public interface HealthCheck {
 }
 ```
 
-Applications are expected to provide health check procedures (implementation of a `HealthCheck`), which will be used by the framework or runtime hosting the application to verify the healthiness of the computing node.
+Applications are expected to provide health check procedures (implementation of a _HealthCheck_), which will be used by the framework or runtime hosting the application to verify the healthiness of the computing node.
 
-The runtime will `call()` the `HealthCheck` which in turn creates a `HealthCheckResponse` that signals the health status to a consuming end:
+The runtime will _call()_ the _HealthCheck_ which in turn creates a _HealthCheckResponse_ that signals the health status to a consuming end:
 
 ```java
 public class HealthCheckResponse {
@@ -72,9 +72,9 @@ public class HealthCheckResponse {
 }
 ```
 
-=== Constructing `HealthCheckResponse`s
+=== Constructing HealthCheckResponse
 
-Application level code is expected to use one of static methods on `HealthCheckResponse` to retrieve a `HealthCheckResponseBuilder` used to construct a response, i.e. :
+Application level code is expected to use one of static methods on _HealthCheckResponse_ to retrieve a _HealthCheckResponseBuilder_ used to construct a response, i.e. :
 
 ```java
 public class SuccessfulCheck implements HealthCheck {
@@ -89,42 +89,42 @@ public class SuccessfulCheck implements HealthCheck {
 
 This specification provides different kinds of health check procedures.
 Difference between them is only semantic.
-The nature of the procedure is defined by annotating the `HealthCheck` procedure with a specific annotation.
+The nature of the procedure is defined by annotating the _HealthCheck_ procedure with a specific annotation.
 
-* Readiness checks defined with `@Readiness` annotation
-* Liveness checks defined with `@Liveness` annotation
-* Backward compatible checks defined with `@Health` annotation
+* Readiness checks defined with _@Readiness_ annotation
+* Liveness checks defined with _@Liveness_ annotation
+* Backward compatible checks defined with _@Health_ annotation
 
 
-A `HealthCheck` procedure with none of the above annotations is not an active procedure and should be ignored.
+A _HealthCheck_ procedure with none of the above annotations is not an active procedure and should be ignored.
 
 === Readiness check
 
 A Health Check for readiness allows third party services to know if the application is ready to process requests or not.
 
-The `@Readiness` annotation must be applied on a `HealthCheck` implementation to define a readiness check procedure, otherwise, this annotation is ignored.
+The _@Readiness_ annotation must be applied on a _HealthCheck_ implementation to define a readiness check procedure, otherwise, this annotation is ignored.
 
 === Liveness check
 
 A Health Check for liveness allows third party services to determine if the application is running.
 This means that if this procedure fails the application can be discarded (terminated, shutdown).
 
-The `@Liveness` annotation must be applied on a `HealthCheck` implementation to define a Liveness check procedure, otherwise, this annotation is ignored.
+The _@Liveness_ annotation must be applied on a _HealthCheck_ implementation to define a Liveness check procedure, otherwise, this annotation is ignored.
 
 
 === Backward compatible check
 
-To provide backward compatibility with previous specification version, a `HealthCheck` implementation with `@Health` annotation is still supported.
+To provide backward compatibility with previous specification version, a _HealthCheck_ implementation with _@Health_ annotation is still supported.
 
-**`@Health` annotation is deprecated**, new procedures shouldn't use it.
+**@Health annotation is deprecated**, new procedures shouldn't use it.
 
 
 == Integration with CDI
 
-Any enabled bean with a bean of type `org.eclipse.microprofile.health.HealthCheck` and `@Liveness`, `@Readiness` or `@Health` qualifier can be used as health check procedure.
+Any enabled bean with a bean of type _org.eclipse.microprofile.health.HealthCheck_ and _@Liveness_, _@Readiness_ or _@Health_ qualifier can be used as health check procedure.
 
 
-Contextual references of health check procedures are invoked by runtime when the outermost protocol entry point (i.e. `http://HOST:PORT/health`) receives an inbound request
+Contextual references of health check procedures are invoked by runtime when the outermost protocol entry point (i.e. _http://HOST:PORT/health_) receives an inbound request
 
 
 ```
@@ -162,9 +162,9 @@ class MyChecks {
 
 == SPI Usage
 
-Implementors of the API are expected to supply implementations of `HealthCheckResponse` and `HealthCheckResponseBuilder` by providing a `HealthCheckResponseProvider` to their implementation. The `HealthCheckResponseProvider` is discovered using the default JDK service loader.
+Implementors of the API are expected to supply implementations of _HealthCheckResponse_ and _HealthCheckResponseBuilder_ by providing a _HealthCheckResponseProvider_ to their implementation. The _HealthCheckResponseProvider_ is discovered using the default JDK service loader.
 
-A `HealthCheckResponseProvider` is used internally to create a `HealthCheckResponseBuilder` which is used to construct a `HealthCheckResponse`. This pattern allows implementors to extend a `HealthCheckResponse` and adapt it to their implementation needs. Common implementation details that fall into this category are invocation and security contexts or anything else required to map a `HealthCheckResponse` to the outermost invocation protocol (i.e. HTTP/JSON).
+A _HealthCheckResponseProvider_ is used internally to create a _HealthCheckResponseBuilder_ which is used to construct a _HealthCheckResponse_. This pattern allows implementors to extend a _HealthCheckResponse_ and adapt it to their implementation needs. Common implementation details that fall into this category are invocation and security contexts or anything else required to map a _HealthCheckResponse_ to the outermost invocation protocol (i.e. HTTP/JSON).
 
 == Contributing