My major questions would be where do I place the quorum (probably a disk and file share witness)
Quorum is a majority agreement, it is not a resource. It used to be a resource until 2003 where the only option was a disk, but this hasn't been the case since Server 2008.
There can only be a single witness, you can't have both a disk and a fileshare. The choice of which to have is going to be based on your favorable scenario during a failure and your internal implementation limits. For example, a company I work with has said absolutely no shared disk to any server, so that rules out a disk as a potential witness.
Most organizations want the whatever is considered the optimal side for their business (though, proper planning and implementation there wouldn't be an "optimal" side) to stay running. In most cases we call this the "primary" side. Generally speaking the witness should be closest to the location that should stay up in case of a true split situation when using windows server 2012R2 or lower. If you're using Windows Server 2016 you will want to look into sites.
And if Asynchronous commit is the only option available because of the geographical distance is it viable to just a have a manual failover option?
Again, depends. Will this ever be failed to? Maybe just in the instance of a true regional DR event where RTO trumps RPO? Will there be any reporting on this new replica? If so, does the reporting require a specific data freshness SLA?
Synchronous will obviously have an overhead and your round trip time (rtt) latency will play the largest factor for long distance AGs, followed next by disk. Asynchronous will obviously not have those problems in terms of reducing the throughput of the workload but will still feel it in terms of data freshness if it is used for reporting.
Remember, if it is a planned downtime you can change the availability mode before performing any activities.
You can absolutely add a 3rd node to a DR site and have it be an asynchronous replica. It'll be a multi-subnet configuration, so be sure you add the MultiSubnetFailover=True to the connection strings to get a successful connection, that is if the drivers you are using support it.
You may want to disable the 3rd node's quorum vote in your configuration. I'm assuming you already have quorum setup correctly with a fileshare witness or something else (if you don't, then get that fixed). You don't want a network glitch to take down the cluster if you also have an issue on one of the nodes at the primary site. Be sure you understand quorum and votes and what's needed to keep production up.
Best Answer
I'd need to see the article where that quote is from to understand the context, but the file share will still be part of the cluster and will still be configured as the witness.
Votes: Node1=Yes, Node2=Yes, Node3=No, File share=Yes
If you ever failover to the other data center, you'll need to create a quorum there. Maybe you'd spin up another node and file share when you failover. Those would be created in the San Jose data center. Once those are in place, add the VM to the cluster and then reconfigure the cluster to use the new file share in the San Jose DC for the witness. After failover, disable the votes for the DC data center. You don't want those resources deciding if you have quorum when there's a network glitch between the two data centers.