Add wrap-and-carry (cyclic/modulo) auto-numbering (#578)

Adds a configurable wrap-at-N counter type to the autonumbering engine
(NumerotationContext + NumerotationContextCommands), covering PLC/rack-style
addressing conventions like "e0.0...e0.7, e1.0...e1.7" (8 channels per
card) generally, rather than hardcoding octal specifically.

- New "wrap" part type (WrapNum, alongside the existing UnitNum/TenNum/
  HundredNum strategies) stores a modulus in addition to the existing
  value/increase/initialvalue fields. Its own next()/previous() only wraps
  its own value modulo the configured modulus -- carrying into (or
  borrowing from) the adjacent part requires visibility across parts,
  which only the composition loop has.
- NumerotationContextCommands::next()/previous() gained carry()/borrow()
  helpers: when a wrap part's own next() would reach/exceed its modulus
  (or go below 0 on previous()), the nearest preceding numeric part is
  bumped by exactly one unit, skipping non-numeric parts (e.g. a "."
  string separator). Wrap parts chain correctly if adjacent (e.g. seconds
  wrapping into minutes wrapping into hours).
- For the leading part of a wrap-and-carry pair to stay fixed except when
  carried into (i.e. actually produce "e0.0...e0.7, e1.0..." rather than
  advancing on every step under its own strategy), its own increase must
  be 0. The increase spinbox's minimum was 1, which made this
  configuration impossible through the UI -- lowered to 0 and documented
  with a tooltip, since this wasn't obvious from the UI alone.
- NumerotationContext gained a 5th pipe-separated field (modulus) in its
  serialized string form, defaulting to 0 (non-wrapping) for every
  existing part type; toXml()/fromXml() persist it as a "modulus" XML
  attribute the same way "initialvalue" is already persisted for
  unitfolio/tenfolio/hundredfolio.
- New "Cyclique (modulo)" entry in the part-type dropdown (numparteditorw),
  available for element, conductor, and folio autonumbering alike, since
  all three already go through NumerotationContextCommands.

Verified in the running app via the numbering config dialog's own
Suivant/Précédent buttons (which call the production
NumerotationContextCommands::next()/previous() directly): a two-part
context (unit, increase=0 + wrap mod 8) produced exactly
e0.0→...→e0.7→e1.0→...→e1.7 on repeated "next", and the exact reverse
(with correct borrowing) on repeated "previous".

sources/autoNum/ui/numparteditorw.h

@@ -49,6 +49,7 @@ class NumPartEditorW : public QWidget
 		enum type {unit,unitfolio,ten,tenfolio, hundred, hundredfolio,
 				   string,idfolio,folio,plant,locmach,
 				   elementline,elementcolumn,elementprefix,
+				   wrap,
 				  };
 		NumerotationContext toNumContext();
 		bool isValid ();
@@ -63,6 +64,7 @@ class NumPartEditorW : public QWidget
 		void on_type_cb_activated(int);
 		void on_value_field_textEdited();
 		void on_increase_spinBox_valueChanged(int);
+		void on_modulus_spinBox_valueChanged(int);
 		void setType (NumPartEditorW::type t, bool=false);
 
 	signals: