debian,ceph.spec: split ceph-osd into shared base and implementation packages

debian,ceph.spec: split ceph-osd into shared base and implementation packages

Previously, ceph-osd packaging had two mutually exclusive flavors that
could only be built one at a time: one with classic OSD and another
with crimson OSD. Both provided /usr/bin/ceph-osd, making them
impossible to coexist and confusing from a user perspective.
This commit restructures the packaging to enable both implementations
to coexist on the same system:

- ceph-osd: Contains shared components (systemd units, sysctl configs,
  common executables like ceph-erasure-code-tool) and depends on exactly
  one OSD implementation
- ceph-osd-classic: Contains the classic OSD implementation binary and
  classic-specific tools
- ceph-osd-crimson: Contains the crimson OSD implementation binary and
  crimson-specific tools

The two implementation packages conflict with each other but both
depend on ceph-osd for shared resources.

Changes:

Debian packaging:

- Revert e5f00d2f
- Add ceph-crimson-osd package
- Add Recommends: ceph-classic-osd to prefer classic on upgrades
- Add Replaces/Breaks for smooth upgrades from old monolithic package
- Create separate .install files for crimson and classic osd packages
  Enforce exact version matching using ${binary:Version}

RPM packaging:

- Use rich dependencies for OR requirement (classic or crimson)
- Add Recommends: ceph-classic-osd for upgrade preference

Upgrade behavior:

Users upgrading from older versions will automatically get
ceph-classic-osd due to the Recommends directive, maintaining
backward compatibility. Users can explicitly choose crimson by
installing ceph-osd-crimson, which will conflict out classic.
Switching between implementations is supported via standard package
operations, with the alternatives system ensuring /usr/bin/ceph-osd
always points to the active implementation.

Signed-off-by: Kefu Chai <k.chai@proxmox.com>