HTTP sessions and TLS sessions are independent.
HTTP keeps track of session usually with HTTP cookies. Requests from a single HTTP session can be sent over multiple TLS connections each with their own TLS sessions.
TLS session is tracked with TLS session ticket. Session ticket keeps track of the encryption parameters (which cipher to use, session key, etc); encryption parameters is usually associated with a single TLS connection, but TLS can also resume a TLS session to create a new TLS connection with the same encryption parameters as a previous connection.
Also, if you have a proxy server, it can multiplex multiple requests from different clients into a single TLS connection, and this means you may have multiple HTTP session in a single TLS connection.
When a client requests an SSL web resource via a browser (ie: a login request) and then follows up with additional requests are all the requests executed in the same SSL session? Or does the browser create and tear down the session with each request?
This is implementation defined. User agents may decide to use multiple TLS connections and/or sessions if it believes doing so will be beneficial to performance. Modern browser will typically open several TLS connections to make HTTP/1.1 requests concurrently up to a limit (usually 4-8 concurrent connections), then reuses those connections as much as possible. Modern browsers will usually use a single TLS connection for HTTP/2 requests as HTTP/2 supports request multiplexing natively.
And do servers track session state across these requests solely through cookies which are encrypted over the SSL protocol
HTTP Servers tracks HTTP session through HTTP cookies only. The TLS part of the Web Server tracks TLS connections, but this is independent of the HTTP sessions. Some Web Server can also use mutual authentication to authenticate user via SSL client certificate; and this can be used to track session as well if the server is configured to pass information about the client certificate into the HTTP request (e.g. as HTTP headers).
or is there any functionality provided through SSL where servers know that the initial request came from the same browser as the following requests?
TLS has session tickets to keep track of TLS sessions.
If it's just via encrypted cookies what is to prevent someone from spoofing the cookie value somehow and making a request with that spoofed cookie thus impersonating the original user?
If an attacker can somehow gets hold of the cookie from your user's browser, you're already screwed.