Core rewrite

[NotRequiem]

This change does not affect any existing old usage of the core.

• Removed all heap and VTable memory usage in the core, making some memory vulnerabilities and memory fragmentation not existent. The core is now based on different contiguos blocks of memory to improve cache locality by the CPU. Any std::vector, std::map, std::stringstream, or any C++ std function that used the heap was replaced with constexpr std::array or raw C-style arrays. std::map handles gaps and sorts keys automatically, but uses tree traversal (O(logN)). Everything was replaced with manual implementations with instant index access

Technique Table: Changed from std::map<enum_flags, technique> to std::array<technique, enum_size + 1>
Memoization (Cache): Changed from std::map<u16, data_t> to std::array<cache_entry, enum_size + 1>
Brand Scoreboard: Changed from std::map<const char*, int> to std::array<brand_entry, MAX_BRANDS>

• The return types of major functions (brand(), type(), conclusion(), get_brand()) do not longer construct any object in memory, and were replaced with direct pointer returns, so just 4 or 8 bytes. Parallelizable functions were added to manipulate char data

• Argument handling is now resolved at compile-time or via direct bit manipulation

• Replaced instances of std::function with raw bool(*)() function pointers

• Since std::vector was removed, custom memory containers like enum_vector and disabled_tech_container were added. push_back(enum_flags f) was marked VMAWARE_CONSTEXPR_14. This allows the list to be populated during static initialization. begin(), end(), size(), operator[]: Marked constexpr.
  The compiler can now potentially optimize loops iterating over these containers into unrolled assembly instructions, because it knows the size and contents of the array at compile time

static constexpr size_t MAX_DISABLED_TECHNIQUES = 64;
struct disabled_tech_container {
    enum_flags flags[MAX_DISABLED_TECHNIQUES]{};
    size_t count = 0;

    VMAWARE_CONSTEXPR_14 void push_back(enum_flags f) {
        if (count < MAX_DISABLED_TECHNIQUES) flags[count++] = f;
    }

    constexpr const enum_flags* begin() const { return flags; }
    constexpr const enum_flags* end() const { return flags + count; }
};
static disabled_tech_container disabled_techniques;

struct enum_vector {
    enum_flags data[enum_size] = { 0 };
    size_t count = 0;

    VMAWARE_CONSTEXPR_14 void push_back(enum_flags f) {
        if (count < enum_size) data[count++] = f;
    }

    constexpr const enum_flags* begin() const { return data; }
    constexpr const enum_flags* end() const { return data + count; }
    constexpr size_t size() const { return count; }
    constexpr const enum_flags& operator[](size_t i) const { return data[i]; }
};

• The core structure that holds a detection method (its certainty score and the function pointer) was modified:

struct technique {
    // ...
    constexpr technique() : points(0), run(nullptr) {}
    constexpr technique(u8 points, bool(*run)()) : points(points), run(run) {}
};

This allows technique objects to be created as "literals". Instead of the CPU having to run instructions to build these objects when the program starts, the compiler bakes the binary representation of these objects directly into the data segment of the executable

To switch from dynamic vectors to static arrays, the sizes must be known at compile time. I converted these to constexpr:
MAX_DISABLED_TECHNIQUES: Set to 64.
MAX_CUSTOM_TECHNIQUES: Set to 32.
MAX_BRANDS: Set to 128.
maximum_points, high_threshold_score, SHORTCUT.

• Some argument validation checks are now done recursively at compile time, example:

template <typename... Args>
static constexpr bool is_empty() {
    return (sizeof...(Args) == 0);
}

[kernelwernel]

Ik a lot of comments here are criticisms in this review, but that doesn't mean the PR in itself is bad. Most of the changes are good, and I didn't feel like it was necessary to point each of the things I liked, since pointing out the problematic parts are more important for the sake of a PR review.

But anyways, I think you did a good job in general. There's just a bit of polishing that's left and some minor modifications. Other than that, it should be good to go.