consider change to default behavior instead of flags --fast-sweep, --serial-lanes (not --force-parallel)

as of 0.3.13, the default operation for MFG and most cases should be :
lmar -p --fast-sweep --serial-lanes --force-parallel

(instead of just lmar -p)
--fast-sweep: implements a binary(ish) edge search middle out. greatly speeds up the measurement but doesn't sample every inner eye point along the axis. For most cases, this is fine. Considering changing default to fast-sweep and having a flag for --slow-sweep or --complete-sweep or something like that.

--serial-lanes : the issue here is that EP (U.2 SSDs) though they by their reporting support margining all 4 lanes at once, It was found that many drives have significant noise with poor repeatability while doing a parallel sweep. After much effort was put into testing different methods, the cleanest was to margin each lane sequentially. (this arg might be better named --seq-lanes, since serial collides a bit with the S in 'SERDES'. )

--force-parallel : (this should remain an argument) This arg regards Root Complex Ports (AMD side). The confusion here is that AMD does not advertise capability for parallel margining of ports. During debug efforts of link instability, lmar was updated to adhear to this advertised capability, which means default -p scan will margin RC ports sequentially. However, comparison of parallel vs sequential data were observed to be identical (and very tight distribution over multiple runs). I forget the details exactly now (it's many months later) but Andy and I both felt there was no reason not to margin RC ports in parallel. But, since default behavior of lmar follows the spec, overriding that capability with --force-parallel is recommended for SP5 socket. This will have to be evaluated on other platforms.