LOG all SQL Server queries with their durations
What is your actual goal? Are you trying to track down a troublesome query, performance tune your whole environment, or is this just out of curiosity?
Ultimately, I wouldn't recommend trying to track and log all queries. I suspect you only really care about poorly performing queries which are an actual business impact.
On most production servers, you will have far more queries that either run quickly enough that even a 10-20% performance gain is barely noticeable, or are already optimized well enough to make any performance tuning poor use of your time.
So instead I'd suggest targeting your performance tuning to queries that actually need it.
In any case, you have a few options:
Query Store
If you are running SQL 2016 or higher, the Query Store is my preferred method. It is very low overhead and provides some neat methods to track query performance over time. Books Online has a good article on using it here. Note that it needs to be enabled per-database, and will only capture information once it has been enabled.
DMVs
sys.dm_exec_query_stats stores aggregated (by query plan) stats around query execution. This can be useful for a high level view of what queries are consuming the most resources on a server. You will not get individual execution statistics (unless it's only run once), so it's not really suitable for identifying &quot;one off&quot; performance issues with normally well behaved queries.
It doesn't include the statement text, but you can get this using the sys.dm_exec_sql_text DMF. As an example:
select top 100 
    qt.text
    , qs.execution_count
    , qs.total_worker_time
    , qs.total_physical_reads
    , qs.total_logical_reads
    , qs.total_physical_writes
    , qs.total_logical_writes
    , qs.creation_time
    , qs.last_execution_time
from
    sys.dm_exec_query_stats as qs
cross apply 
    sys.dm_exec_sql_text(qs.sql_handle) as qt
order by 
    total_worker_time desc

Extended Events
If you are really set on capturing every single query, your best bet will be to use XEs. Understand that there will be a significant performance overhead if you go down this route (especially if you're capturing things like the callstack, or doing something crazy like filtering by sql text with a predicate), and it's not something I'd recommend doing by any means.
If you set something like this up, I would suggest being extremely careful and not allowing it to run without monitoring its impact.