Refactoring to make the API emerge

[rdentato]

The code was almost 100% ready to be refactored in three functions:

• llmNew()
• llmGenerate()
• llmFree()

I touched the code as little as possible, Just moved from the main() function to their own functions.

[madroidmaq]

@rdentato Great work, and thank you for your effort! I've been thinking of doing something similar, especially since the current main function is quite lengthy.

Regarding the new function names, I have a few suggestions:

1. The llm prefix seems unnecessary. Given that the current project is llama2, it inherently represents LLM. Including the prefix feels redundant.
2. The naming of the llm_t structure should be consistent with the naming convention of our previous structures. I suggest using PascalCase (for example, LlmT). However, I'm not sure about the meaning of T here. It should have a more descriptive name. Moreover, it seems to encompass too many parameters/information. It would be a good idea to break it down into smaller components.

I might consider a breakdown similar to the following:

typedef struct {
    Config config;
    TransformerWeights weights;
    int fd;              // file descriptor for memory mapping
    float* data;         // memory mapped data pointer
    ssize_t file_size;   // size of the checkpoint file in bytes

} Model;

typedef struct {
    char** vocab;
    float* vocab_scores;
} Tokenizer;

Model from(char *checkpoint) {
    // ...
}

Tokenizer from(char *tokenizer) {
    // ...    
}

void generate(Model *model, Tokenizer *tokenizer, RunState *state) {
    // ...
}

void main() {
    // args ....
    Model model = from(checkpoint_path);
    Tokenizer tokenizer = from(tokenizer_path);
    RunState state;
    malloc_run_state(&state, &config);

    generate(model,tokenizer,state)

    free()
}

The above API definitions resemble those of HuggingFace. Users familiar with the HuggingFace API will immediately understand the purpose and functionality of each function when they encounter this section.