PHP class architecture and dependency injection
Alright, let's start with your concerns, and then move on to the actual review:


A prepared statement costs about 50 times a normal statement. However, that cost is on the database server's side (i.e. on MySQL's side), preparing a statement A, then clearing the statement object on PHP, then preparing the same statement A (with different parameters) will not incur a penalty, because the query is cached by mysql.
A dependency injection container has advantages and disadvantages. It simplifies the dependency wiring process at the cost of magic. A dependency injection container is completely optional, don't sweat about it (especially in small projects).
What are you abstracting? That's a question that you should ask yourself every time you create a class or a layer (which is a bunch of classes that have the same purpose). You seem to trying to abstract the PDO object, hiding it from the user. But why? PDO is an abstraction on its own, you don't really need to abstract it. What you should abstract is either


Storage itself. Make a mapper that takes an object and stores/fetches it from storage. Note that I didn't say MySQL because mappers are storage agnostic, then you can work seamlessly across different storage types.
The SQL language. Make a criteria based API (also commonly known as DSL). Something like this: $db-&gt;select()-&gt;from('table')-&gt;where(Database::EQUALS("column", "value"))-&gt;limit(10); It's up to you.


Your current abstractions don't really add value to an application. Why would I use your class over plain 'ol PDO?
Yes, it should, and I'll explain. When you create an object, it should do one thing and one thing only. Your user object should be responsible for keeping track of data about the user. It's an object that represents a single user in your data model. 

Your user should not be aware of its own means of storage. A user specifically can come from many places. It can come from a register form, it can come from a database, it can come from a migration CSV file containing hundreds of users to be inserted at bulk. 

As a result, your user should be storage agnostic, it should not care where the data came from, it should just accept it in the constructor, and  work with what it's got.




A few more points:


Always keep your code properly and consistently indented.
Don't catch the database exception and kill the script every time when there's an error. Let the caller decide! What if I can live without a database and will rely on alternative storage methods until I can get the database back online?
Don't rely on constants for the database credentials! Pass the to the constructor!

public function openConnection(string $host, string $dbname, string $username, string $password) {

By default, refrain from having public fields. Everything should be as private as possible, and only what you want to expose to the outside world is public.
Assuming your user object is bound to the database, a database object would be part of the object's state, it's bound to that database instance. Why not pass it in the constructor and keep it as a property?
PHP7 added the ability to type-hint scalars (such as string), use that in your advantage.
Your instance methods seem to return a new user object, rather than changing the current one, that seems counter intuitive, make changes to the current object. If the consumer wants a different user, they should create a new User.