Following up on #3231

- Add BIT and TEST macros
- Add _APPLY_ macros to stepper.cpp to help with consolidation
- Consolidate code in stepper.cpp using macros
- Apply standards in stepper.cpp
- Use >= 0 instead of > -1 as a better semantic
- Replace DUAL_Y_CARRIAGE with Y_DUAL_STEPPER_DRIVERS

- Both TMC, L6470 and pin-driven drivers work.
- All can be mixed and matched as needed.

Add digipot i2c control for MCP4451
Allow M907 to set i2c digipot currents in amps
Fix Makefile to allow Azteeg motherboards
Fix Makefile to allow Wire libraries only
Add beeper pin for Azteeg X3 Pro

Check the Readme for instruction how to enable and configure the feature

Diffed and merged, preserving my updates

Reviert previous change of #if BLAH_PIN > 0 to #if defined(BLAH_PIN) &&
BLAH_PIN > -1. Unfortunately some times pin 0 is used. For my sins I've
gone through and replaced all unsafe checks of #if BLAH_PIN > -1 with
the safe version.

The new version of the library means that PANELOLU no longer needs to be
defined in LiquidTWI.h (the library file can be used as is) and the new
version of the library also enables the buzzer on the Panucatt VIKI
panel.

Refactor configuration to try to make items clearer (what defines a
panel vs what is user changeable).

Also fix compile time check in Marlin.pde

This includes refactoring the buttons code to remove a large amount of
non-pin dependent duplication from pins.h.

Changed to report on individual lines with "TRIGGERED" or "open" instead of "H" or "L" on one line as H&L could be confused with logic levels High and Low which may be wrong if using inverted logic.  Added strings to language.h.

Fixed typo "deu" in English language that was fixed in #134 but got added back in via 9f7f7354f5

Added function 'setTargetedHotend' that turns into a function an operation repeated 3 times through the M-codes processing.

This modification saves a few bytes that can be used to add support for new commands.

Some discussion of the issue is here http://forums.reprap.org/read.php?181,118329,page=1

Conflicts:

	Marlin/Configuration.h

motor current and microstepping pins.

The cli(); at the start of the kill() function also stops the internal
arduino timer which stops updating of millis() which prevents the
display of the "KILLED." message.
The new function updates the display directly without checking any
timers.

Replace the large macro HOMEAXIS with a function.  This avoids the
compiler generating three copies of largely identical code.  The
saving is 724 bytes of program memory.

We make use of XYZ_CONSTS_FROM_CONFIG to provide convenient
array-shaped access to MAX_LENGTH, HOME_RETRACT_MM and HOME_DIR.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

SERIAL_ECHOPAIR implies, eventually, two calls to MYSERIAL.print.  One
of these has FORCE_INLINE for a per-character loop, and both involve
constructing a method call rather than a simple function call.

Produce better and smaller code by providing three specialised
functions serial_echopair.  This saves 672 bytes of program memory
(with EEPROM_SETTINGS and SDSUPPORT enabled).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by a new home_pos[] which includes the adjustment.  We also have to
adjust the uses of [XYZ]_{MIN,MAX}_POS similarly - see below.


To allow axis_is_at_home to be written as a function taking an axis
index rather than a macro taking an axis letter, we provide
constant arrays in program memory containing the values of
[XYZ]_{MIN,MAX,HOME}_POS from the compiled-in configuration.

This is done with some helper macros to deal with the declaration
(XYZ_CONSTS_FROM_CONFIG) and definition of the inline function which
does the program memory access.

We also introduce the overloaded function read_pgm_any, whose
instances are produced with DEFINE_PGM_READ_ANY, which allows the
access functions to automatically produce the correct type.

The type- and pointer-massaging code in the access function boils
down, when compiled, to a simple program memory access.


A question arises: if the M206 offset is set, should this adjustment
to the home position shift or change the possible range of movement
permitted by the software endstops ?

The documentation in Configuration.h describes these limits as:
    // Travel limits after homing
Since this is a file containing physical limits, and actual suggested
values for these configuration parameters appear to include a certain
amount of slop, I've taken the view that these should be regarded as
nominal physical distances from the limit switches, and that the
permissible travel should be unaffected by M206.

So for example with the (rather unrealistic)
  #define X_HOME_DIR -1
  #define X_MIN_POS -20
  #define X_HOME_POS 0
  #define X_MAX_POS 100
no matter the setting of M206 X, the machine would be permitted
to move from 20mm "beyond" the limit switch trigger point in
the negative X direction and 100mm away from the limit switch in
the positive X direction, for a total travel of 120mm.

With M206 X-10 that would be considered to correspond to X coordinates
-30 to +90.  With M206 X+10 that would be considered to correspond to
X coordinates -10 to +110.


fixes #200 (in ErikZalm/Marlin).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

If [XYZ]_HOME_POS and [XYZ]_MIN_POS aren't 0, these corrections are
wrong.  Use the same logic as in Marlin.pde:prepare_move: ie, clamp to
[XYZ]_{MIN,MAX}_POS.

While we're here, put this cut-and-paste code in a function
clamp_to_software_endstops.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>