ret-cont-recursive-nix: Improve syntax highlighting

rfcs/0000-ret-cont-recursive-nix.md

@@ -48,13 +48,16 @@ stdenv.mkDerivation {
 The other main reason is other build systems should be translated to Nix without vendoring tons of autogenerated code in Nixpkgs.
 For this, case, the one difference is we need to generate some Nix first.
 ```nix
-installPhase = ''
-  bazel2nix # new bit
-  for o in $outputs; do
-    pkg=$(nix-build -E '((import <nixpkgs> {}).callPackage ./. {}).'"$o")
-    cp -r $pkg ${!o}
-  done
-'';
+stdenv.mkDerivation {
+  ...
+  installPhase = ''
+    bazel2nix # new bit
+    for o in $outputs; do
+      pkg=$(nix-build -E '((import <nixpkgs> {}).callPackage ./. {}).'"$o")
+      cp -r $pkg ${!o}
+    done
+  '';
+}
 ```
 
 "Ret-cont" recursive Nix, short for "return-continuation" recursive Nix, is a different take on recursive Nix.
@@ -106,10 +109,13 @@ Sandboxing and Darwin are crucial to Nix today, and we shouldn't sacrifice eithe
 With "ret-cont" recursive Nix, actual builds are never nested, so we don't need any fancy constraints on the derivation "runtime" (i.e. the code that actually performs and isolates builds).
 Furthermore, we can skip needing to talk to the daemon by just producing a local store:
 ```nix
-outputs = [ "drv" "store" ];
-installPhase = ''
-  mv $(nix-instantiate --store $store -E '((import <nixpkgs> {}).callPackage ./. {}).'"$o") $drv
-'';
+stdenv.mkDerivation {
+  ...
+  outputs = [ "drv" "store" ];
+  installPhase = ''
+    mv $(nix-instantiate --store $store -E '((import <nixpkgs> {}).callPackage ./. {}).'"$o") $drv
+  '';
+}
 ```
 This further simplifies the implementation.
 Derivations remain built exactly as today, with only logic *between* building steps that is entirely platform-agnostic changing.