Update guidelines.md (#125)

https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-39 follow to `Dangerous strict equalities` recommendations. To avoid confusion in future I propose to use unique link ...#incorrect-versions-of-solidity

Author: enginer

development-guidelines/guidelines.md

@@ -82,7 +82,7 @@ The architecture of your codebase should make your code easy to review. Avoid ar
 ### Solidity
 
 - **Favor Solidity 0.5 or 0.6.** In our opinion, Solidity 0.5 and 0.6 are more secure and have better built-in practices than 0.4. Solidity 0.7 is too young to be used in production and needs time to mature.
-- **Use a stable release to compile; use the latest release to check for warnings.** Check that your code has no reported issues with the latest compiler version. However, Solidity has a fast release cycle and has a history of compiler bugs, so we do not recommend the latest version for deployment (see Slither’s [solc version recommendation](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-39)).
+- **Use a stable release to compile; use the latest release to check for warnings.** Check that your code has no reported issues with the latest compiler version. However, Solidity has a fast release cycle and has a history of compiler bugs, so we do not recommend the latest version for deployment (see Slither’s [solc version recommendation](https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-versions-of-solidity)).
 - **Do not use inline assembly.** Assembly requires EVM expertise. Do not write EVM code if you have not _mastered_ the yellow paper.
 
 ## Deployment guidelines