Set command side-effect category for WithRetry - #540

StackExchange.Redis 3.1.0 added WithRetry, which replays failed operations
according to a policy bounded by the command's declared side-effect category.
Commands it does not recognise fall back to CommandRetryNever, and it knows
nothing about module commands - so today *nothing* NRedisStack issues is
eligible for retry.

Categorize all 153 builder commands. SerializedCommand gains a CommandFlags
category as the first constructor argument, masked on construction to the
retry-category region (bits 13-17) plus the server-specific bit (18), so the
parameter cannot smuggle in a replica preference or FireAndForget. The
uncategorized constructors are [Obsolete] and CS0618 is an error inside the
library, so a new command cannot be added without declaring what a replay of
it would do. An internal EffectiveFlags property combines the category with
the library-wide defaults (absorbing the DEBUG-only NoRedirect from Auxiliary).

The library keeps its StackExchange.Redis 3.0.x floor: CommandCategories
declares the values as casts rather than referencing the 3.1.0 named members,
which are [Experimental] under SER007. On 3.0.x the bits fall outside that
version's user-selectable mask and are silently discarded, reproducing current
behaviour exactly; on 3.1.0+ they take effect. The test project overrides to
3.1.0 and asserts each rung against the named member, so an upstream
renumbering fails loudly instead of silently re-categorizing everything.

Notable calls:

- BF.ADD/MADD/INSERT are WriteChecked: bloom adds are monotone, so a replay is
  a state no-op that only changes the returned 0/1.
- CF.ADD/INSERT/DEL are WriteAccumulating: a cuckoo filter is a multiset, so a
  replay changes the counts.
- FT.CURSOR READ is WriteAccumulating, not read-only - reading advances the
  cursor, so a replay skips a page rather than repeating one. It and FT.CURSOR
  DEL, BF/CF.SCANDUMP and cursored FT.AGGREGATE carry ServerSpecific, which
  strips failover while still permitting a same-server retry.
- FT.CONFIG (GET as well as SET) is ServerAdmin|ServerSpecific, matching how
  SE.Redis treats plain CONFIG; a different member can be configured
  differently, so GET is not meaningfully safer.
- The blocking core pops are WriteAccumulating: they are destructive reads, so
  a replay pops a further element and the first one is already lost.
- TS.ADD/TS.MADD are uniformly WriteAccumulating for now; see the comment in
  TimeSeriesCommandsBuilder for why the overload taking TsAddParams cannot see
  which of three possible rungs applies.