anchor.diff:  === RecorderContext
   
   `org.jboss.shamrock.deployment.recording.RecorderContext` provides some convenience methods to enhance bytecode recording,
  -this includes the ability to register creation functions for classes without a no-args constructor, to register an object
  +this includes the ability to register creation functions for classes without no-arg constructors, to register an object
   substitution (basically a transformer from a non-serializable object to a serializable one and vice versa), and to create
   a class proxy. This interface can be directly injected as a method parameter into any `@Recorder` method.
   
  
positive.code: 
  == Configuration
  
  Configuration is done via `@ConfigProperty`, this section is TBD.
  
  == Bytecode Recording
  
  One of the main outputs of the build process is recorded bytecode. This bytecode actually sets up the runtime environment,
  for example in order to start Undertow the resulting application will have some bytecode that directly registers all
  Servlet instances and then starts Undertow.
  
  As writing bytecode directly is incredibly complex this is instead done via bytecode recorders. At deployment time invocations
  are made on proxy instances of template objects that contain the actual runtime logic, and these invocations are recorded,
  including the value of method parameters. Bytecode is then created to do these same invocations on the actual template
  object at runtime.
  
  This is done by adding a `@Record` annotation to a `@BuildStep` method, and injecting a `@Template` annotated class
  from the runtime module. A proxy of the template will be injected into the method, and any method invocations that are
  made will be recorded, and will be run at application startup.
  
  Methods on a template can return a value, which must be proxiable (if you want to return a non-proxiable item wrap it
  in `org.jboss.shamrock.runtime.RuntimeValue`). These proxies may not be invoked directly, however they can be passed
  into other template methods. This can be any template method, including from other `@Record` methods, so a common pattern
  is to produce `BuildItem` instances that wrap the results of these template invocations.
  
  For instance in order to make arbitrary changes to the Servlet deployment Undertow has a `ServletExtensionBuildItem`,
  that is a `MultiBuildItem` that wraps a `ServletExtension` instance. I can return a `ServletExtension` from a template
  in another module, and Undertow will consume it and pass it into the template method that starts Undertow.
  
  At runtime the bytecode will be invoked in the order it is generated. This means that build step dependencies implicitly
  
negative.code: == Testing Extensions
  
  Testing of extensions should be done with the `org.jboss.shamrock.test.ShamrockUnitTest` runner. This runner allows
  for Arquillian-style tests that test specific functionalities. It is not intended for testing user applications, as this
  should be done via `org.jboss.shamrock.test.ShamrockTest`. The main difference between these test runners is that
  `ShamrockTest` simply boots the application once at the start of the run, while `ShamrockUnitTest` deploys a custom
  Shamrock application for each test class.
  
  These tests should be placed in the deployment module, if additional Shamrock modules are required for testing
  their deployment modules should also be added as test scoped dependencies.
  
  An example test class may look like:
  
  