Custom Rules: Implement Configurable Rule Prefix for Custom Rules

~Currently, when publishing a custom rule, the system automatically assigns a Core-ID in the format `CORE-######`. This prefix is hardcoded as "CORE" in the codebase. We need to make this prefix configurable to allow different prefixes (e.g., "SGS") for different rule types while maintaining the same sequential numbering format.~ Currently when running a validation, you need to use -lr to run non-CORE ID'ed rules. It would be good to add logic that does not require a CORE ID in engine for validations, outside of -lr

## Current Implementation
The current implementation uses the following function to generate IDs:
```typescript
const next_core_id = async () =>
`CORE-${(parseInt((await STORAGE_PROVIDER.maxCoreId()).slice(-6)) + 1)
.toString()
.padStart(6, "0")}`;
```
This relies on the `maxCoreId` function that uses a hardcoded "CORE" prefix:
```typescript
const maxCoreId = async (): Promise => {
const query = `
SELECT VALUE root
FROM (
SELECT MAX(rules.json.Core.Id) ?? "CORE-000000"
AS CoreId
FROM rules
WHERE rules.json.Core.Id
LIKE "CORE-______"
) root
`;
return (await rulesHistoryContainer.items.query(query).fetchNext())
.resources[0]["CoreId"];
};
```
Requirements
- ~Allow users to specify a custom prefix when publishing a rule~
- ~Make the prefix configurable via UI input~
- ~Maintain the six-digit sequential numbering format (######)~
- ~Update the SQL query to dynamically use the specified prefix~
- ~Ensure proper error handling for invalid prefixes~
- ~Consider adding prefix validation (e.g., uppercase letters only, max length)~
- allow validations to run with -r with non-core IDs, this would be done in conjuncture with custom standards/version