First refactor train

[Ssukriti]

As part of first refactor , I have created a function for train which will accept predefined dataclasses as arguments instead of taking all possible parameters.
This was done for the following reasons:

1. more readability - now I know exactly what arguments train function accepts
2. allows for easier parameter validation + usability - since users have to pass either Loraconfig dataclass or promptuning dataclass, they know upfront what parameters are relevant for each type.
3. modular code - rather than having everything in a big main function, we can have train, load and run in future

The main function is reading all arguments from command line and passing relevant params to train() as an example.

I will move the main() to an example script going forward, and we can continue to call that main() function with command line arguments or let it serve as a reference for users who want to call train() function directly .

Usage of the script has not changed in this PR. All code changes are structural only, and I verified that pt, lora and ft work same was as they do in main branch

python tuning/sft_trainer.py  \               
--model_name_or_path $MODEL_PATH  \
--data_path $DATA_PATH  \
--output_dir $OUTPUT_PATH  \
--num_train_epochs 5  \
--per_device_train_batch_size 4  \
--per_device_eval_batch_size 4  \
--gradient_accumulation_steps 4  \
--evaluation_strategy "no"  \
--save_strategy "epoch"  \
--learning_rate 1e-5  \
--weight_decay 0.  \
--warmup_ratio 0.03  \
--lr_scheduler_type "cosine"  \
--logging_steps 1  \
--include_tokens_per_second  \
--packing False  \
--response_template "\n### Label:"  \
--dataset_text_field "output" \
--use_flash_attn False  \
--tokenizer_name_or_path $MODEL_PATH \
--torch_dtype "float32" \
--peft_method None

[Ssukriti]

dataclass names have to be camel case as per Python naming conventions. I want to add a black formatter to this repo going forward, and it would fail without this change. To handle name resolution with HF peft, I have renamed the file to peft_config. In code we would refer to it as peft_config.LoraConfig
If there is a need to further to distinguish the two in future, we can rename them as CustomLoraConfig

[Ssukriti]

I got rid of this. users can pass the relevant peft config object in train() that will be passed directly to the trainer

[Ssukriti]

since the repo only supports CausalLMs we need not expose task_type to user as an argument.

[Ssukriti]

since train() now accepts the peft_config objects, it makes sense to use those to get the corresponding HF peft config.
Earlier functionality to pass all kwargs has been moved to create_tuning_config utility which can be combined with get_hf_peft_config if needed.

[raghukiran1224]

lgtm