refactor: Migrate NECommon to areg::common namespace

[caliph1998]

Summary

Migrates all NECommon:: references to areg::common:: across the entire codebase as part of the namespace modernization effort (#656). This is the first namespace migration PR, covering the NECommon module.

Changes

• Wrapped NECommon constants and types in the areg::common namespace inside framework/areg/base/NECommon.hpp
• Updated all framework modules (areg, aregextend, areglogger, logcollector, logobserver) to use common:: within areg:: namespace scope
• Updated all 27+ examples to use fully qualified areg::common:: for framework constants
• Updated unit tests to use areg::common::
• Preserved 8 examples that define their own local NECommon.hpp with app-specific constants (e.g., 16_pubmesh, 20_winchat) — only their framework constant references were updated, app-specific constants remain as NECommon::
• Used areg::common:: directly (without AREG_NAMESPACE_USE macro) in code not yet wrapped in the areg:: namespace (examples, tests, aregextend) to keep builds working incrementally

Testing

• Clean build passes: cmake --build build --clean-first -j20 at 100%
• All 359 unit tests pass: ctest --test-dir build --output-on-failure
• Generated code in product/generate/ auto-regenerates correctly from .siml files

Notes

• This PR targets the feature/655-api-modernization-and-refactoring branch, not master
• Subsequent PRs will migrate other NE* namespaces following the same pattern

[caliph1998]

Hi @aregtech,

I've been working on the namespace migration for NECommon and have a draft PR ready on branch feature/656-necommon-to-areg-common targeting feature/655-api-modernization-and-refactoring.

This PR wraps all NECommon constants and types in the areg::common namespace and updates all references across framework, examples, and tests. Build passes at 100% and all 359 unit tests pass.

But, I noticed the upstream branch has had significant changes since I branched off (PR #673 removing NE/IE/TE file prefixes, macro reductions, etc.), so there will be merge conflicts to resolve. Before I spend time rebasing, I wanted to check:

Is the areg::common namespace approach I took on still aligned with the your intended direction? I want to make sure before resolving what will be a fairly large merge.
Also the file naming: The open issue description says renaming NECommon.hpp to common.hpp, which would break the PascalCase convention used by every other header in the framework. I did that so now it's common.hpp, or should it be Common.hpp instead?

Note: As said in the PR description, I had to directly use areg:: namespace in most directories to keep the PR buildable. The reason is we are incrementally changing the namespaces so other subnamespaces like NEServices are not yet wrapped in areg so they can't see common:: namespace. This is an intermediary step and the direct use of the areg:: namespace will be dropped once all namespaces and classes are wrapped

[aregtech]

Hi @caliph1998,

Huge thanks for the PR!

I’ve been doing some heavy lifting on a major refactor lately (specifically a lot of file and namespace renaming), and I want to make sure my changes don't clash with yours moving forward.

To keep our workflow smooth and avoid merge conflicts:

• Please assign the relevant ticket to yourself before starting. If you don't have the permissions to do so, just send me a quick message!
• For smaller, specific changes (like renaming NECommon specifically, rather than a "rename all namespaces" sweep), it’s best to create a dedicated sub-task.
• Since the main namespace ticket was unassigned, I assumed it was open for work. Seeing an "Assigned" status is my signal to sync with you before I push any big updates.

If you’d like to be deeply involved in this refactoring project, I’d love to add you to the official Contributors list. This will give you more permissions to create issues, review code, and modify sources directly.

Let me know what you think!

[caliph1998]

@aregtech

Yes, I’d be happy to assign this issue to myself, but it seems I don’t currently have the necessary permissions. I would really appreciate it if you could assign it to me.

I also agree that this is a fairly large issue and would likely benefit from being broken down into smaller sub-issues. Once I’m added to the contributors list and have the appropriate permissions, I’ll be able to help with organizing it further.

Thank you very much for your help!

[aregtech]

@caliph1998 , you are now in the list of collaborators. As soon as you accept invitation, you'd be able to make changes.
Please feel free to create issues with smaller tasks. It would be perfect if you create a sub-issue of a bigger task.
When working on an issue, please assign to yourself.

About NECommon namespace. It is very probable that all classes, structs and enums of areg-framework will be wrapped in areg namespace. It means neither NECommon, nor areg::common will remain.
This is only relevant to areg framework --> path framework/areg/...

There is a file describing how the structure will be changed.

You are welcome to make better suggestion.

If anything is unclear, you find a conflict in description or something is confusing, please feel free to ask.

---

2. Namespace Strategy

2.1 Framework namespace is always areg::

The AREG_NAMESPACE compile option is removed. All framework types live in namespace areg.
Users who want shorter names use standard C++ mechanisms:

// Import specific types
using areg::String;
using areg::ResultType;

// Using-directive in .cpp files only (never in headers)
using namespace areg;

2.2 Namespace hierarchy (2 namespaces for areg library)

All public types from the areg library live in a single flat areg:: namespace.
Directories organize source files for developers; the namespace organizes the API for users.
This matches Abseil (absl:: for everything) and Qt (Qt:: for everything) conventions.

areg::                       // ALL areg library types from all directories:
                             //   base/:      String, Thread, Mutex, ByteBuffer, Rect,
                             //               Point, Size, SystemTime, HashMap, ArrayList, etc.
                             //   component/: Component, Proxy, Stub, Timer, ResultType,
                             //               ServiceType, RequestType, ModelState, etc.
                             //   ipc/:       RemoteConnection, ConnectionType, ConnectionState,
                             //               RemoteServiceId, SendPolicy, etc.
                             //   logging/:   LogPriority, LogRecord, ScopeInfo, ConfigKey,
                             //               LayoutTag, LogStatus, Grouping, NodeType, etc.
                             //   persist/:   ConfigKeys, PropertyRecord, etc.
                             //   appbase/:   AppState, EntryTypesEnabling, etc.
areg::os::                   // OS abstraction layer: platform-specific primitives
                             //   MutexPosix, SpinLockWin32, SyncObjectPosix, etc.
                             //   Class names carry platform suffix; only one compiles per platform
                             //   Located in private/posix/ and private/win32/ directories

aregext::                    // Extended library (separate from areg library):
                             //   ServiceOption, SystemServiceState, ConnectionBehavior, etc.
mtrouter::                   // Router application (not in areg::)
logcollector::               // Log collector application (not in areg::)

Why flat areg:: instead of sub-namespaces:

• Areg's core design principle is transport transparency — threading, IPC, and logging are one unified system, not isolated subsystems. Sub-namespaces contradict this.
• areg::component::Component says "component" three times. areg::Component says it once.
• Sockets live in base/, used by both ipc/ and logging/ — sub-namespaces would force an arbitrary assignment.
• Developers type areg:: and see everything. No guessing which sub-namespace a type belongs to.
• Only 2 namespaces to learn: areg:: (public API) and areg::os:: (platform internals).
• The #include path already tells you the source directory: #include "areg/component/Component.hpp" — the namespace doesn't need to repeat it.

2.3 Previous namespace → new location mapping

Old NE Namespace	Types move to	Rationale
NEApplication	areg::	AppState, EntryTypesEnabling
NECommon	areg::	Constants, SortOrder, IndexPosition, CookieId, RingOverlap
NEMath	areg::	Rect, Point, Size, Coord, LargeInteger, CompareResult, DigitSign
NEMemory	areg::	BufferHeader, RawByteBuffer, BufferType, MessageResult, Align
NESocket	areg::	SocketAddress, UserData
NEString	areg::	CharDefs, Radix
NEUtilities	areg::	SystemTime
NEDebug	areg::	DebugPriority (private by file location)
NESyncTypesIX	areg::os::	POSIX sync types (platform suffix on class names)
NERegistry	areg::	ModelState, ComponentEntry, ServiceEntry
NEService	areg::	ResultType, ServiceType, RequestType, DataState, etc.
NEConnection	areg::	Connection constants (private by file location)
NERemoteService	areg::	RemoteConnection, ConnectionType, RemoteServiceId
NELogging	areg::	LogPriority, LogRecord, ScopeInfo, LogDataType, etc.
NELogOptions	areg::	ConfigKey, LayoutTag, LogStatus (private by file location)
NEPersistence	areg::	ConfigKeys, PropertyRecord
NESystemService	aregext::	ServiceOption, SystemServiceState (separate library)
NELogCollectorSettings	logcollector::	App-level, not in areg::
NEMultitargetRouterSettings	mtrouter::	App-level, not in areg::