Encoder position precision clarification

**Is your feature request related to a problem? Please describe.**
Not an error, but clarification of precision. I am trying get a common implementation of BBs vs say RPi. Comparison of current sysFS result size vs prior mmap direct register access which was long int. Back then I thought the hardware was 64 bits. Today the library returns int via atoi( ).

**Describe the solution you'd like**
Of course, a return value that captures the hardware size is best. Is it 64 bits or 32 bits?
OBTW, refs such as https://en.wikibooks.org/wiki/C_Programming/stdlib.h/atoi gripe about deficiencies in atoi, like not thread safe. Preferred implementation seems to be atol( ). There is also the issue of mixed long int vs unsigned long int. I'm pretty weak on coding for this difference. I take the BB hardware to be unsigned in nature, but with correct underflow and correct max value, it may look like a signed int. The rc_test_encoder_eqep function clearly returns singed ints and backwards motion shows as negative numbers. Even refs like https://www.tutorialspoint.com/c_standard_library/c_function_strtol.htm don't seem to be careful with signed vs unsigned.

**Describe alternatives you've considered**
As I try for a common user level implementation between BBs and RPis, I have chased the Raspbian encoder kernel driver, which seems to be a standard Linux available driver. It is clearly software based and take two definable GPIOs for inputs. Multiple instances are allowed. There is a dtoverlay to declare them at boot time. The community doesn't seem to use these for robotics but for rotary encoders that are used for volume knobs. The typical max value is small. The size is not well specified. At least, I couldn't find it. I ended up using the relative response that simply returns +1 or -1 and doing by own accumulation. This leaves the max value more in my control. Of course, you can tell me to use extra hardware such as the long-promised Raspberry Beret. But we still need some thought on the software interface design.

**Additional context**
While I'm at it and considering RPis, I started thinking about long duration operations for our bots. To date, driving around the lab floor doesn't challenge the 32 bit size, I suppose. I did start driving an R/C car with a BBB around the parking lot. We need to start implementing features that account for roll over. The TI hardware has interrupts for that. It hurts my head trying to think about how to do that correctly. If we don't do it well ahead of time (and well), it will be very difficult to identify as a problem in the field when the bot is on mile 10 of 50, or whatever.