docs(readme): fix rstcheck violation [skip ci]

https://travis-ci.org/github/myii/varnish-formula/builds/731609027#L259

```
docs/TOFS_pattern.rst:18: (ERROR/3) Unknown target name: "data".
```

docs/TOFS_pattern.rst

@@ -15,7 +15,7 @@ To avoid this situation we can use the `pillar mechanism <http://docs.saltstack.
 
 There are a variety of approaches on usage of pillar and templates seen in `saltstack-formulas <https://github.com/saltstack-formulas>`_ repositories. `Some <https://github.com/saltstack-formulas/nginx-formula/pull/18>`_ `developments <https://github.com/saltstack-formulas/php-formula/pull/14>`_ stress the initial purpose of pillar data into an storage for most of possible variables for a determined system configuration. This, in my opinion, shifting too much load from the original template files approach. Adding up some `non-trivial Jinja <https://github.com/spsoit/nginx-formula/blob/81de880fe0276dd9488ffa15bc78944c0fc2b919/nginx/ng/files/nginx.conf>`_ code as essential part of composing the state file definitely makes Saltstack state files (hence formulas) more difficult to read. The extreme of this approach is that we could end up with a new render mechanism, implemented in Jinja, storing everything needed in pillar data to compose configurations. Additionally, we are establishing a strong dependency with the Jinja renderer. 
 
-Opposed to the _put in file_roots the code and in pillar the data_ approach, there's the *pillar as a store for a set of key-values* approach. A full-blown configuration file abstracted in pillar and jinja is complicated to develop, understand and maintain. I think it's better a simpler approach keeping a configuration file templated using just a basic (non-extensive but extensible) set of pillar values.
+Opposed to the *put the code in file_roots and the data in pillars* approach, there's the *pillar as a store for a set of key-values* approach. A full-blown configuration file abstracted in pillar and jinja is complicated to develop, understand and maintain. I think it's better a simpler approach keeping a configuration file templated using just a basic (non-extensive but extensible) set of pillar values.
 
 On reusability of Saltstack state files
 ---------------------------------------