SQL Server Replication with Historical Tables Is it possible to replicate a SQL Server database and for the replica to have temporal/historical tables?

Details:
I have a production system, running SQL Server 2014. I want to have a replica database and I also want to track historical changes.

It would be ideal to replicate the production Database to a SQL Server 2016 instance and to track changes with temporal/historical tables.

Is this possible?
Is this possible on Azure?

Edit: Part 2

After David Browne's excellent answer and doing some further reading, I have more direction and more questions. 
I will be using an Azure SQL Database / Logical Server.
I will be using transactional replication because 
1. it is supported on Azure SQL Database and 
2. we can have temporal tables disabled on the publisher (Sql Server 2014) and temporal tables enabled on the subscriber (Azure SQL Database / Logical Server) As per David Browne's excellent answer. 

Part 2 Questions:
How much additional load is placed on the "publisher" database when it becomes a publisher?

How can I avoid downtime and locks on the publisher when setting this up?

I have multiple "publisher" databases. Can I have multiple subscriber databases on one Azure SQL Database / Logical Server instance?
Is it possible to replicate a SQL Server database and for the replica to have temporal/historical tables?

Yes.  If you use an AG Replica, the primary database and replicas will all have the same Temporal Tables.
If you use Transactional Replication, you can have a Temporal Table at the subscriber, where the table at the publisher is non-temporal.
If you use Change Tracking or Change Data Capture you can use the change data to ship and apply to a temporal table in a reporting database.
See

Usage of replication technologies is limited.
Always On: Fully supported
Change Data Capture and Change Data Tracking: Supported
only on the current table
Snapshot and transactional replication:
Only supported for a single publisher without temporal being enabled
and one subscriber with temporal enabled. In this case, the publisher
is used for an OLTP workload while subscriber serves for offloading
reporting (including 'AS OF' querying). Use of multiple subscribers is
not supported since this scenario may lead to inconsistent temporal
data as each of them would depend on the local system clock.
Merge
replication: Not supported for temporal tables

Temporal Table Considerations and Limitations