* Disallow filament change while paused

* Use kinematic movemements in pause_print and resume_print

If the SD print is paused, it cannot be stopped

Following up on #3231

Keep "astyled" reformatting

- `SD_DETECT_PIN` replaces `SDCARDDETECT`
- `SD_DETECT_INVERTED` replaces `SDCARDDETECTINVERTED`
- Revise the description of `SD_DETECT_INVERTED`
- Add a note about the override of `SD_DETECT_INVERTED` in
`Conditionals.h`

- Rename the pin so it can be tested with `PIN_EXISTS`
- Fix some incorrect tests for `SDCARDDETECT`

Apply `ENABLED` / `DISABLED` macros to files needing only a small
number of changes.

- Apply standards to cardreader.*
- Fix minor issues with cardreader.cpp
- Apply standards to some other stale regions

Replace instances of the number 13 with FILENAME_LENGTH where
appropriate.

Replace instances of the number 13 with FILENAME_LENGTH where
appropriate.

First iteration of alphabetical sorting for SD cards, both
slow+efficient and fast+rammy. Option for folders to sort first, last,
or not at all.

For the MORE_RAM option we need to buffer both the short and long
names, even though long names are sometimes redundant. Worst case, all
the names are max length. We can save some RAM by not storing these. We
could save more RAM by only storing the visible part of the long name.

With this option, always keeps the dir in RAM, doubling as a cache for
getfilename. A board with only 8K of SRAM is cutting it very close.

First iteration of alphabetical sorting for SD cards, both
slow+efficient and fast+rammy. Option for folders to sort first, last,
or not at all.

# The first commit's message is:
SD Card Alpha Sorting

First iteration of alphabetical sorting for SD cards, both
slow+efficient and fast+rammy. Option for folders to sort first, last,
or not at all.

# This is the 2nd commit message:

Expand on More RAM concept, address minor bugs

# This is the 3rd commit message:

Improvements, more SORT_USES_MORE_RAM

With this option, always keeps the dir in RAM, doubling as a cache for
getfilename. A board with only 8K of SRAM is cutting it very close.

# This is the 4th commit message:

Completed SORT_USES_MORE_RAM implementation

For the MORE_RAM option we need to buffer both the short and long
names, even though long names are sometimes redundant. Worst case, all
the names are max length. We can save some RAM by not storing these. We
could save more RAM by only storing the visible part of the long name.

For the MORE_RAM option we need to buffer both the short and long
names, even though long names are sometimes redundant. Worst case, all
the names are max length. We can save some RAM by not storing these. We
could save more RAM by only storing the visible part of the long name.

With this option, always keeps the dir in RAM, doubling as a cache for
getfilename. A board with only 8K of SRAM is cutting it very close.

First iteration of alphabetical sorting for SD cards, both
slow+efficient and fast+rammy. Option for folders to sort first, last,
or not at all.

For the MORE_RAM option we need to buffer both the short and long
names, even though long names are sometimes redundant. Worst case, all
the names are max length. We can save some RAM by not storing these. We
could save more RAM by only storing the visible part of the long name.

With this option, always keeps the dir in RAM, doubling as a cache for
getfilename. A board with only 8K of SRAM is cutting it very close.

First iteration of alphabetical sorting for SD cards, both
slow+efficient and fast+rammy. Option for folders to sort first, last,
or not at all.

If a print is stopped, it would be nice in the future to write a file with the printer state, the filename of the print, and the position within the print.
this file could be read, to continue a previously stopped print.
not finished yet.

by overloading M32 it is now possible to execute gcode files from other gcode files, with a fixed recursion level.
This can be used e.g. for having a real start.g and end.g somewhere on the sd card, which are then called from the normal print file.
Another usecase would be to have macro-files for nozzle-change and layerchange.
I have not tested the speedwise performance. The testing was done with pronterface.

syntax:
normal call from sd card will open the new file and continue executing there.
M32 !/path/filename#
this however will call the new file and return to the caller file.
M32 P !/path/filename#
with the optional "S<position>" the  file starting position can be set.
this is for continuing prints from a previous location.