Move constants and types into class scope

[cleishm]

Move constants and types into class scope. Also move mux into private scope.

This is an API breaking change. Resolves #20.

[cleishm]

This enum feels awkward. Given it's a breaking change, would you consider changing the API to specify floating/pullup separately for the encoder and the switch? Then you wouldn't need the enum either - a bool would suffice (unless you wanted to add support for a reversed logic level?).

E.g.

rotaryEncoder.setEncoderInternalPullup(false);
rotaryEncoder.setButtonInternalPullup(false);

or perhaps:

rotaryEncoder.disableEncoderInternalPullup(); // rotaryEncoder.enableEncoderInternalPullup();
rotaryEncoder.disableButtonInternalPullup();  // rotaryEncoder.enableButtonInternalPullup();

[cleishm]

Alternatively, you could avoid methods entirely and provide direction on pull-ups as constructor args. This would avoid surprising errors where someone attempts to call these after calling begin().

[cleishm]

Ok - I'm not sure I actually like passing them in constructor arguments. It gets unwieldy. Here's the commit for that: 07538dd

One could go further and replace the constructor arguments with a parameters struct. For c++17 and above, this would also work with named initialization in some cases, which is somewhat elegant - except that the user must still declare the arguments in-order for the initializer to work. Commit for that is here: 3ec2214

Not sure I like either of those especially, so perhaps methods-that-must-be-called-before-begin is the way to go.

[MaffooClock]

As it's been a while since I wrote this library, chunks of it are a bit fuzzy in my memory, and I haven't taken the time to deeply refresh myself since you started pouring all your effort into it.

But I can say this much: I chose to use an Enum rather than multiple .set...() or .enable()/.disable() methods purely because it looked "prettier" to me (and I thought it would make it easy to use). You're obviously more skilled in C++ than me and see a opportunities to optimize, so I certainly appreciate that.

...perhaps methods-that-must-be-called-before-begin is the way to go

After thinking through this a bit, I would agree with this.

[cleishm]

I think the issue is that there are mixing concerns - the encoder and the button are two separate devices (albeit in one physical package). Ditto with the VCC pin: I personally would've made that a concern for the user to take care of externally to the library.

But it's all personal preference and there is no standard for any of this (that I'm aware of). And it's your library, so you get to choose :)

I've pushed a commit to this PR that provides individual methods.