Restore the output latch with the pin, and correct the note on the negative ports

[ainyan03]

Two things a probe leaves behind after it borrows a pin, found while fixing
board identification in M5Unified (m5stack/M5Unified#331).

The output latch is not part of a backup

pin_backup_t saved the mux, the routing and the output enable, but not the
level the pin was driving. Releasing an open drain line means letting the latch
go high, and that is how every probe ends, so a pin that had been driving low
came back driving high once the enable was restored.

Restoring the latch in place was not enough on its own. Putting the pad
configuration back can turn an open drain output into a push-pull one while the
enable is still set and the latch is still high, and the pin drives that high
before the latch is ever reached. The order is now:

1. take the output down,
2. put the latch back while nothing is driving,
3. restore the configuration and routing,
4. enable the output again only if that is how the pin was found.

The enable is set and cleared through its own registers instead of read back
and written, so a pin being restored on another core is not caught inside a
read-modify-write.

Board autodetection is the heaviest user of this class, so it is also the best
place to see it still works. Checked on hardware: M5StopWatch (468x468), Core2
v1.1 (320x240), PaperS3 (540x960) and an AtomS3RCam all come up, identify
themselves, and keep running.

The note about the negative ports is no longer true

It told a sketch to use port -2 because no library takes it. Board
identification in M5Unified takes it, so following that advice would hand a
sketch the slot a probe is about to reopen on other pins — and a transfer does
not check that the slot is still the one it was given, so the wrong pins would
move with nothing to show for it.

The note now describes what happens instead: both slots are borrowed while a
board is being brought up, and a sketch that wants one should open it
afterwards.