Replace AtomicUsize with Cell<usize> in the recursion counter

[wzzzzd]

This is a simple PR that eliminates the weird AtomicUsize.

Closes #1097

[alamb]

Thank you for the contribution @wzzzzd -- I am not familiar with the relative performance characteristics of Cell vs AtomicUsize -- I wonder did you see the atomic increments show up in a performance trace?

I think there are likely far more heavy weight operations (like string copying) that dominate most sql parsing operations

[coveralls]

Pull Request Test Coverage Report for Build 7555548027

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.001%) to 87.859%

---

Totals
Change from base Build 7542509865:	0.001%
Covered Lines:	18851
Relevant Lines:	21456

---

💛 - Coveralls

[wzzzzd]

Thank you for the contribution @wzzzzd -- I am not familiar with the relative performance characteristics of Cell vs AtomicUsize -- I wonder did you see the atomic increments show up in a performance trace?

I think there are likely far more heavy weight operations (like string copying) that dominate most sql parsing operations

I wrote a microbenchmark to compare the performance of Cell vs AtomicUsize in a deeply nested query, and the result shows that their difference is negligible (<5%) :(
Nevertheless, I think Cell should be preferred from the perspective of code style, since it does not indicate parallelism or concurrency (sql parsing is purely single-threaded).

[jmhain]

+1 for this change, I was going to open a PR myself until I found this one. Using an atomic here is weird and unnecessary, since Cell exists for exactly this purpose (interior mutability of a value not shared between threads). The Rc wrapping it already makes it so that RecursionCounter and thus Parser are not Send or Sync so this should have no effect on the crate's api either.

[alamb]

Thanks @wzzzzd and @jmhain