Start to pull out TWIT_get() function

[hadley]

@llrs this work isn't completed, but I think it's in a good place for you to take a look to make sure you understand how TWIT_get() works. I'd recommend that you start by reading the source code for TWIT_get(), asking me about any techniques that I've used that you don't yet understand. Then take a look at the functions that I've rewritten.

[llrs]

I think I understood all the code but not why you write it that way. I understand the withr::local_options but don't understand why you use it instead of the options and on.exit.
Another thing I don't understand well is about stop_for_status. You don't use httr::stop_for_status but deferred to check_status, but there is also the warn_for_twitter_status (used many times with httr::GET) and check_status_code (seems to be used with TWIT_POST). Why this choice? Should some of these be eliminated ? (Perhaps not as part of this PR)

Also the scipen option used on the package are a bit inconsistent but the max found is 15 (not sure if it will matter or is just an error). But I got some post with an id of 19 numbers, perhaps a bigger number is reasonable?

It might be too soon but the API is moving to v2. Perhaps a new argument to TWIT_GET with default version = "1.1", could be set. So that when new api v2 endpoints start to be implemented we don't need to go back and modify this function.

[hadley]

I use with::local_options() because it's simpler, and makes it harder to make mistakes (like forgetting add = TRUE).

Totally agree that we'll need to rationalise all the ways of checking status — my plan is to get rid of warn_for_twitter_status() and check_status_code() as I rewrite those functions (and as we eliminate use of bare httr calls)

In general, I don't think it's a good idea to speculatively add arguments to functions. It's too hard to predict what the right API will be until you have some example code. But I do think TWIT_get() and

[llrs]

I was thinking mainly on the academic research product track, highly requested lately (#468), is on API v2. But certainly we can wait till we get the package on shape.

[hadley]

@llrs I think it's the right approach, I just don't think it's the right time — we can add an easy way to use v2 once we start implementing those functions. Anyway, since you're on board, I'm going to merge these commits. If they cause merge conflicts in any of your other PRs please let me know and I can take a look.