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.
This is required by the proposed new DRM/vt(4) integration (https://github.com/freebsd/drm-kmod/pull/243).