Support Mega2560 board (and other 8-bit boards)

[ClutchplateDude]

Change frequency to long

Resolves #403

[marcelstoer]

I am personally not a fan of these _ variable/parameter name prefixes either. I understand the compiler warnings but for consistency reasons one cannot change this only here.

[ClutchplateDude]

What do you suggest? Change them all? We compile with warnings as errors so it was a blocker for us which is why we have forked it for now. But would like to use the official repo when possible.

[marcelstoer]

What do you suggest?

Not sure...not being too familiar with the early history of this lib makes this a difficult question for me. As changing the constructor parameters is the less invasive of the two options, I guess I would prefer that.

Also, while analyzing I realized the _ prefix wasn't applied consistently anyway. The geometry parameter (OLEDDISPLAY_GEOMETRY) is always just called g rather than _g.

[ClutchplateDude]

Yeah, there's often a tradeoff of readability/maintainability vs. backwards compatibility, or not making breaking changes. But I think internals should be open to change, since they should not be used by consumers.
As far as coding standards go, in my C++ experience, using underscores is usually reserved for class members and function parameters get normal arguments. But that's like arguing about spaces vs. tabs.... you'll always find at least one of each side in any group :-)

[ClutchplateDude]

Looking at all the source, It's pretty inconsistent:

• all the hardware-related files (SSD1306* and SH1106*) use the _ prefix for members. Function arguments do not have a leading _ except for ctor args
• all the OLED* files use camelCased member and argument names for all functions and ctors

I would convert all ctors in the SSD* and SH* files to use camelCased arguments. I can do that in this PR if desired.

[marcelstoer]

I can do that in this PR if desired.

That'd be much appreciated, thanks.