The attached patch is a work-in-progress for making sure that all of
Gnus' code only accesses group infos via the relevant macros --
essentially hiding the fact that group infos are implemented as lists,
in anticipation of eventually being able to re-implement them as structs
at some point in the future.

Essentially, "(nth 3 info)" becomes "(gnus-info-marks info)", and so
one.

It also replaces uses of "gnus-info-set-*" with "(setf (gnus-info-* ".
The setter macros aren't deprecated, though.

My main question is about the use of the EXTEND argument to
`gnus-info-set-marks', `gnus-info-set-method', and
`gnus-info-set-params'. In the current patch, I have left the setter
intact wherever the EXTEND argument is passed, until I can figure this
out.

If I could understand why _some_ of the infos are expected to be short a
few elements (newly-created groups?), I would rather provide a
`make-gnus-info' function (again, in anticipation of a struct
constructor), which could be called with the elements of an info (either
as a list or spread) and return an info filled-out with nils where
necessary. Then that could be used wherever we expect a short info.

There's also the weird spot in gnus-sum.el:6183 where we're chopping off
nil elements from the end of an info list, I don't know why.

One last bit I'm uncertain about is in `nnvirtual-request-update-info',
where I've replaced this:

      (setcar (cddr info) nnvirtual-mapping-reads)
      (if (nthcdr 3 info)
	  (setcar (nthcdr 3 info) nnvirtual-mapping-marks)
	(when nnvirtual-mapping-marks
	  (setcdr (nthcdr 2 info) (list nnvirtual-mapping-marks))))

with this:

      (setf (gnus-info-read info) nnvirtual-mapping-reads)
      (when nnvirtual-mapping-marks
	(setf (gnus-info-marks info) nnvirtual-mapping-marks))

It seems to work fine, but to be honest I don't really understand the
original logic.

Eric