fix yaml tag to allow code formatting/highlighting

Author: ddsharpe

README.md

@@ -180,7 +180,7 @@ As the example above shows, the `SecurityConfiguration` element has no named sub
 
 When modeling configuration attributes that can have multiple values, the WebLogic Deploy Tooling tries to make this as painless as possible.  For example, the `Target` attribute on resources can have zero or more clusters and/or servers specified.  When specifying the value of such list attributes, the user has freedom to specify them as a list or as a comma-delimited string (comma is the only recognized delimiter for lists).  For attributes where the values can legally contain commas, the items must be specified as a list.  Examples of each are shown below.
 
-```$yaml
+```yaml
 resources:
     JDBCSystemResource:
         MyStringDataSource:
@@ -217,7 +217,7 @@ One of the primary goals of the WebLogic Deploy Tooling is to support a sparse m
 #### Modeling Security Providers
 One place where the semantics are different is for WebLogic security providers.  Because provider ordering is important, and to make sure that the ordering is correctly set in the newly created domain, the Create Domain Tool will look for security providers of each base type (for example, Authentication Providers, Credential Mappers, and such) to see if any are included in the model.  If so, the tool will make sure that  the providers only listed for a type are present in the resulting domain so that the providers are created in the necessary order.  For example, if the model specified an `LDAPAuthenticator` and an `LDAPX509IdentityAsserter` similar to what is shown below, the `DefaultAuthenticator` and `DefaultIdentityAsserters` will be deleted.  If no providers for a base type are listed in the model, then the default providers will be left untouched.
 
-```$yaml
+```yaml
 topology:
     SecurityConfiguration:
         Realm:
@@ -259,7 +259,7 @@ topology:
 
 To keep the `DefaultAuthenticator` and `DefaultIdentityAsserter`, simply add the default names and types in the correct positions in the model's `AuthenticationProvider` list.  If desired, settings on the default providers can be changed, as shown below.
 
-```$yaml
+```yaml
 topology:
     SecurityConfiguration:
         Realm:

site/create.md

@@ -131,7 +131,7 @@ To create more complex domains with clusters of different types, it is necessary
 
 Then, use the `ServerGroupTargetingLimits` map in the `domainInfo` section to limit the targeting of the Web Services Manager, SOA, and OSB server groups to the `soa_cluster` or `osb_cluster`, as appropriate.  In the example below, notice that the `JRF-MAN-SVR` server group is not listed; therefore, it will use the default targeting and be targeted to all managed servers.  The value of each element in this section is a logical list of server and/or cluster names.  As shown in the example, the value for each server group can be specified as a list, a comma-separated string, or a single-valued string.  There is no semantic difference between listing a cluster's member server names versus using the cluster name; the example uses these simply to show what is possible.
 
-```$yaml
+```yaml
 domainInfo:
     AdminUserName: weblogic
     AdminPassword: welcome1

site/variable_injection.md

@@ -35,7 +35,7 @@ Here is an example of a `model_variable_injector.json` file using the PORT keywo
 
 Below is a model snippet that shows injected variables in the port attributes.
 
-```$yaml
+```yaml
 
 topology:
     Name: soa_domain
@@ -143,7 +143,7 @@ The following is an example of how to effectively use the `regexp` directive lis
 
 In the model, we expect to find a URL like the following:
 
-```$yaml
+```yaml
     JDBCSystemResource:
         Database1:
             JdbcResource: