Fix inline code formatting in documentation

Signed-off-by: Hao <kyrieeeee2@gmail.com>

docs/modules/ROOT/pages/servlet/oauth2/resource-server/multitenancy.adoc

@@ -320,7 +320,7 @@ class TenantJWSKeySelector(tenants: TenantRepository) : JWTClaimsSetAwareJWSKeyS
 ----
 ======
 <1> A hypothetical source for tenant information
-<2> A cache for `JWSKeySelector`s, keyed by tenant identifier
+<2> A cache for ``JWSKeySelector``s, keyed by tenant identifier
 <3> Looking up the tenant is more secure than simply calculating the JWK Set endpoint on the fly - the lookup acts as a list of allowed tenants
 <4> Create a `JWSKeySelector` via the types of keys that come back from the JWK Set endpoint - the lazy lookup here means that you don't need to configure all tenants at startup
 

docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc

@@ -639,7 +639,7 @@ class MyCustomSecurityConfiguration  {
 ----
 ======
 
-In this way, the set of `RelyingPartyRegistration`s will refresh based on {spring-framework-reference-url}integration/cache/store-configuration.html[the cache's eviction schedule].
+In this way, the set of ``RelyingPartyRegistration``s will refresh based on {spring-framework-reference-url}integration/cache/store-configuration.html[the cache's eviction schedule].
 
 [[servlet-saml2login-relyingpartyregistration]]
 == RelyingPartyRegistration
@@ -971,9 +971,9 @@ As seen so far, Spring Security resolves the `RelyingPartyRegistration` by looki
 Depending on the use case, a number of other strategies are also employed to derive one.
 For example:
 
-* For processing `<saml2:Response>`s, the `RelyingPartyRegistration` is looked up from the associated `<saml2:AuthRequest>` or from the `<saml2:Response#Issuer>` element
-* For processing `<saml2:LogoutRequest>`s, the `RelyingPartyRegistration` is looked up from the currently logged in user or from the `<saml2:LogoutRequest#Issuer>` element
-* For publishing metadata, the `RelyingPartyRegistration`s are looked up from any repository that also implements `Iterable<RelyingPartyRegistration>`
+* For processing ``<saml2:Response>``s, the `RelyingPartyRegistration` is looked up from the associated `<saml2:AuthRequest>` or from the `<saml2:Response#Issuer>` element
+* For processing ``<saml2:LogoutRequest>``s, the `RelyingPartyRegistration` is looked up from the currently logged in user or from the `<saml2:LogoutRequest#Issuer>` element
+* For publishing metadata, the ``RelyingPartyRegistration``s are looked up from any repository that also implements `Iterable<RelyingPartyRegistration>`
 
 When this needs adjustment, you can turn to the specific components for each of these endpoints targeted at customizing this: