[rcore_desktop_sdl] Grow dropFilePaths dynamically when file is dragged ontop of window

[jestarray]

The SDL platform allocates 1024 filepaths when user drag/drops file ontop of the Window. Why was it done this way? I don't know, I tried to find where this limit was specified in raylibs config and couldn't!

It turns out GLFW platform layer does not even enforce an arbitrary 1024 limit! It just grows it as needed.
https://github.com/jestarray/raylib/blob/master/src/platforms/rcore_desktop_glfw.c#L2066

// GLFW VERSION:
static void WindowDropCallback(GLFWwindow *window, int count, const char **paths)
{
    if (count > 0)
    {
        // In case previous dropped filepaths have not been freed, free them
        if (CORE.Window.dropFileCount > 0)
        {
            for (unsigned int i = 0; i < CORE.Window.dropFileCount; i++) RL_FREE(CORE.Window.dropFilepaths[i]);

            RL_FREE(CORE.Window.dropFilepaths);

            CORE.Window.dropFileCount = 0;
            CORE.Window.dropFilepaths = NULL;
        }

        // WARNING: Paths are freed by GLFW when the callback returns, keeping an internal copy
        CORE.Window.dropFileCount = count;
        CORE.Window.dropFilepaths = (char **)RL_CALLOC(CORE.Window.dropFileCount, sizeof(char *));

        for (unsigned int i = 0; i < CORE.Window.dropFileCount; i++)
        {
            CORE.Window.dropFilepaths[i] = (char *)RL_CALLOC(MAX_FILEPATH_LENGTH, sizeof(char));
            snprintf(CORE.Window.dropFilepaths[i], MAX_FILEPATH_LENGTH, "%s", paths[i]);
        }
    }
}

(Interestingly the GLFW platform layer also clears the previous dropFilePaths but that should be discussed in another issue. The GLFW one technically shouldn't clear the old dropped paths)

This PR aligns the SDL platform layer behavior closer to GLFW in that just grow the paths dynamically, which simplifies the code a lot because it removes the weird 1024 initial allocation, and a limitation that isn't really defined anywhere else. Either way, user dragging a file ontop of window is a very infrequent and rare usecase and is unlikely to be the source of problems if we let it grow unbounded(people have to clear with UnloadDroppedFiles themselves anyways)