vt(4): New bitblt_text variant making a copy before unlocking vt_buf

[Why]
In the DRM drivers and the integration with vt(4), we need to execute
DRM code outside of the vtbuf_lock. The reason is that this DRM code
acquires locks which can't be acquired when vtbuf_lock, an MTX_SPIN
mutex, is already held.

[How]
A vt(4) backend can now set the vd_bitblt_after_vtbuf_unlock flag to
true if it wants to be called outside of vt_buf_lock.

In this case, vt(4) uses an internal version of bitblt_text that uses
the vd_drawn arrays, plus a new vd_pos_to_flush array, to track
characters to draw/refresh. This internal version then uses the
backend's bitblt_bmp callback to draw the characters after vt_buf has
been unlocked.

Drawing borders and CPU logos is also deferred after the vt_buf lock is
released for the same reason.

We introduce another lock (a default mutex), only used when the
vd_bitblt_after_vtbuf_unlock flag is set, to replace part the role of
the vt_buf lock and manage concurrent calls to vt_flush().

The SC_NO_CONSDRAWN define is dropped because we now always need the
vd_drawn arrays.

Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D42057