To be short:
Without a ledger recording everything, it won't be possible to know whether Alice had ever signed another double-spending transaction. Even if we have a ledger, or even better, a tamper-evident, append-only ledger (which is the inherent nature of blockchain), it's still enough, because the ledger itself could still be maliciously truncated & appended with dishonest new records. Therefore we need a consensus mechanism to allow every participant of the system to know which ledger is valid without a central authority. In Bitcoin, such mechanism is Proof-of-Work, aka PoW or mining.
Note that if a full node doesn't check everything, it would allow much more malicious things including inflation/counterfeit/theft.
why can’t the verification only check against transactions signed by Alice, why does it have to check against the entire blockchain?
Why can’t it just check against Alice’s other transactions since you know she controls that coin.
In reality a full node checks everything in the blockchain, including Alice's ones. Only after checking every transaction in the blockchain can a full node know all Alice's transactions. (in the beginning I didn't notice this point, thanks to @chytrik!)
Once Alice spent some of her bitcoins, any sane & in-sync full node would delete corresponding UTXO entry from its UTXO set database, so that if Alice wants to spend the same coins once again, any sane full node would spot its violation against rules & discard such transaction.
Would it be correct to say that the full nodes check to see if the sender(Alice’s) signature is valid. And they check against double spends by seeing if the hash value that is included (of the transaction where Alice received the bitcoin) has ever been used an another transaction?
Yes, it's correct. In reality it has been done in a much more efficient way without intensively reading the blockchain.
Validation of the blockchain of Bitcoin is progressive in real world, which still matches the "checking against the entire blockchain" criteria in theory.
The Bitcoin blockchain is simply a ledger containing "transaction history" only. The "final/historical balance" is not (yet) committed to the blockchain. Although Satoshi Nakamoto's whitepaper didn't mention these terms, essentially the blockchain itself is the "transaction history", and the UTXO set (which is recalculated from the blockchain by each full node on its own. In other words it's "implied" by the blockchain) is the "final balance of everyone" or "fully-detailed ownership information of all existing bitcoins".
"Ownership" means what it literally means. It's technically the scriptPubkey of each transaction output, which is a script validating digital signature against a public key hash in most cases.
"Existing" means that spending a bitcoin is essentailly deleting corresponding UTXO entry in the database. Oh, in most cases it also creates new UTXO entries, which are the actual payment to the payee and the change sent back to the payer generally.
In reality, the blockchain validation is a progressive process that, the full node just query & update the UTXO set database while reading each block, so that the historical block could be even directly deleted, which is exactly what the currently implemented "blockchain pruning" feature actually does.
Why the historical blocks can be simply discarded? Because, the historical blocks are no longer needed at all in the follow-up validation process, where only the UTXO set needs to be queried & updated. In other words, the "effects" of each transaction in each block is actually reflected on the UTXO set already.
Generally, a full node downloads & verifies the whole blockchain from the genesis block (oh, the genesis block itself is hard-coded), so that even if the blockchain pruning feature is enabled (so that all old block files are simply deleted), it still matches the "checking against the entire blockchain" criteria in theory.
(However there's still a detail that the assumevalid feature is enabled by default, so that a full node won't actually check everything of the blockchain. assumevalid is basically a block hash hard-coded by the developers, which means at least the developers themselves have fully validated all previous blocks before it, let alone thousands of other running full nodes all around the world. If you want the full node software to do real full validation that all historical blocks would be still fully validated, you need to turn off this feature)
However, preventing double-spending is not as simple as checking everything within a (individual "forked branch" of) blockchain. Even if a full node checks everything in the blockchain, Alice could still make up a "forked branck" of the blockchain ledger where she sent her bitcoins to herself, instead of the original payee, if she wants to double-spend - that's exactly why Bitcoin needs a consensus mechanism, which is Proof-of-Work, aka PoW or mining.
(PoW or consensus mechanism is actually not a simple thing like that. For example, an attacker can DoS the network by making infinite forks as well)
Anyone can be a miner, however any block needs some work (mining, which consumes electricity) accumulated on it to be accepted by other participants (full node or SPV) of the network, so that making up lies (invalid blocks) would inevitably have real costs. Making valid blocks also has costs, however this would be "compensated" by the rewards, including newly-issued bitcoins and transaction fees.
Double-spending (forked branch of) blockchain is (inevitably) valid against the rules as well (not like the case that an invalid blockchain always violates the rules), however being "valid" doesn't mean being "winning".
A valid blockchain has to accumulate the most work at same time to be the winning one, otherwise it still won't be accepted by a full node.
That's the well-known "the longest chain rule" (which was actually a tiny but serious mistake corrected by Satoshi himself, to be then changed to "the most accumulated work rule"). Together with other validation rules enforced by every full node, the ruleset incentivises miners to keep honest (only making valid blocks at the chain tip to extend the valid & winning chain even longer).
(Note that SPV client cannot validate the blockchain on its own, therefore it would simply follow the chain with the most accumulated work blindly, however it can still notice whether more than one forks are present)
A malicious miner doing the double-spending faces the risk that his forked chain could be eventually rejected by the network if he won't be able to keep his forked chain to accumulate the most work (among all forked branches, including the "honest" one) on it.
According to the calculations in Satoshi's whitepaper, an attacker (including both miners as an attackers themselves and "dishonest" miners in collusion with the attacker) with more than 50% of hashpower theoretically has 100% probability to be succeed, if he can maintain this for a long enough time. If the attacker doesn't have more than 50% of hashpower, he would inevitably face exponentially dropping success probability as the confirmation number grows.
