Closes #12234

@britta-wstnr at the end of the day I don't think the numpy.dtype I considered in #12234 will be tractable/worth it as:

1. there can be corrupt files (uncommon but do exist) and we can only find them by actually trying to read each buffer
2. there can be acquisition skips and these need to be handled properly (currentlny easily handled in a loop... not easily if we try to vectorize)
3. the single-sample case is pretty rare and sounds like there should be a fix at the acq end soon (?)
4. there is a nice workaround of reading the files once with MNE-Python then writing them out with buffer_size_sec=1., then the I/O is no longer slow

Okay with you to close the associated issue when this is merged?

In the meantime this PR cleans up and speeds up our tag code, on my system it:

1. Speeds up the single-sample-buffer snippet from ENH: Speed up FIF IO #12234 by a factor of about 2
2. Speeds up pytest mne/io/fiff from 23.79s to 20.46s
3. Simplifies the Tag logic and functions, especially involving when to fid.seek to a new position in a file (it's explicit now rather than implicit)
4. Removes a completely unused copy_tree which is already in a private namespace (mne._fiff) so no need to deprecate, can just remove
5. Prefers using explicit file positions to using fid.tell because this function was surprisingly a source of slowdowns in the single-sample buffer case