Isn't 2.0 quite a bit different?
AFAIK, Microchip has never done (nor claimed) anything specific to allow Studio to import sketches from the IDE 2.0.That said, there isn't that much that has changed in 2.0 WRT locations of files and cores and such. (Hmm. I think in 1.x, there was still a copy of the AVR core and tools in the Programs Files directory of the IDE, but in 2.x, everything has moved to the AppData location.)
It's not entirely clear that Studio ever got past the 1.5ish "revised 3rd party specs" that moved 3rd party boards to the AppData directories, or that it ever worked "well", even before that.
It's not clear whether Studio is under "active" development, or whether Microchip is going to abandon it and migrate users to MPLABX. :-(
it seems to not have properly imported the arduino libraries. For example, "Arduino.h" is missing.
Arduino.h is considered part of the Arduino Core, rather than a "library." (although that "core" code and it's include files might be regarded as a library by Studio...)
I have no idea whether I should use AVR XC8 or GCC, or what this even means in practice.
You should use gcc (the Arduino IDE uses gcc.)
XC8 is essentially GCC with added restrictions, and perhaps different libraries. Last time I looked, XC8 had essentially broken floating point support for AVR by replacing the avr-libc functions with code that was about 10x bigger. :-(
What is the best way for me to move forward with this? My codebase is currently not very large, and apart from analogRead(), delay() and some register constants (like PORTD, DDRD etc)
What is your actual goal? If you are just after a "better" IDE for Arduino sketches, that's going to be different than if you want to transition "past" the Arduino framework entirely.
delay() is easily replaced by _delay_ms() from avr-libc. (but replacing millis() is harder.)
PORTD, DDRD, etc, is NOT from Arduino; those are the Atmel-provided definitions.
In either case, you'll need to pay more attention to a bunch of the stuff that you've admitted to not knowing, with more diffuse documentation, less community support, and less actual "steal-able" code for supporting random external peripherals.